Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.requestly.com/llms.txt

Use this file to discover all available pages before exploring further.

Requestly keeps a built-in cookie jar that captures cookies from API responses and replays them on later requests. This mirrors how a browser handles cookies, so you can reproduce session-based flows (login, then call protected endpoints) without copying values around by hand.
The cookie jar is shared across all your projects on this device. It is stored locally and never synced to the cloud, so session tokens stay on the machine that captured them. Switching projects or environments does not switch the jar.
1

Click Cookies in the footer

The Cookies button is in the application footer at the bottom of the window. Clicking it opens the Cookie manager modal.
2

Browse cookies by domain

The Cookies tab lists every cookie in the jar, grouped by host. Click a host row to expand it and see the cookies stored for that domain.

​
How cookies are captured

When a response includes one or more Set-Cookie headers, Requestly parses each cookie and stores it in the jar. You do not need to do anything to enable this. The next time you send a request whose URL matches the cookie’s domain and path, Requestly attaches the cookie to that request as a Cookie header. Matching follows standard browser rules (RFC 6265):
  • Cookies are matched on the request URL’s hostname and path.
  • A cookie with Domain=.example.com is sent to api.example.com, www.example.com, and any other subdomain.
  • A cookie with no Domain attribute is scoped to the exact host that set it.
  • Path scoping is enforced. A cookie with Path=/api is not sent to /.
If you set a Cookie header manually on a request, your value wins. The jar will not overwrite a header you wrote yourself.
You can plant cookies in the jar without sending a request first. This is useful when you want to seed a session token from another tool, or when you are testing how an endpoint behaves under a specific cookie.
1

Open the add cookie modal

In the Cookies tab, click the + button next to the search field. The tooltip reads Add cookie (any domain).To add a cookie scoped to a specific host that already appears in the list, click the + button on that host’s row instead. The modal title shows the host so you know which domain the cookie will land on.
2

Paste a Set-Cookie value

The modal accepts a single Set-Cookie header value, the same string a server would send. For example:
sessionId=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
Supported attributes: Domain, Path, Expires, Max-Age, Secure, HttpOnly, SameSite, Partitioned. Hover the help icon next to the modal title for a quick reference.When Domain= is omitted, the cookie is scoped to the host shown in the modal title.
3

Save

Click Save. The cookie appears under its host in the Cookies tab and will be attached to matching requests from now on.

​
Edit, delete, or clear cookies

Hover any cookie row to reveal its action buttons:
  • Edit cookie opens the same modal pre-filled with the existing Set-Cookie string. Change anything, then save.
  • Delete cookie removes a single cookie immediately.
To clear cookies in bulk:
  • Clear cookies for this domain is the trash icon on a host row. It removes every cookie under that host after a confirmation prompt.
  • Clear all cookies is the sweep icon next to the search field. It empties the entire jar after a confirmation prompt.
Clearing cookies is local and immediate. There is no undo. If you cleared cookies you needed, the only way to recover them is to send the request that originally set them.
The search input at the top of the Cookies tab filters the list as you type. Search matches across host, name, and path, so you can locate a single cookie even when the jar holds hundreds of entries across many domains. Each cookie row shows badges and icons that summarize its attributes:
  • An Expires date or Session label. Expired cookies show a red Expired badge but stay in the jar until you remove them.
  • A lock icon means Secure is set: the cookie is only sent over HTTPS.
  • A shield icon means HttpOnly is set: the cookie is hidden from scripts.
  • A SameSite badge (Lax, Strict, or None) reflects the cookie’s SameSite attribute.

​
Allow scripts to read cookies

Pre and post-request scripts can read and write cookies, but only for domains you have explicitly allowed. This keeps a third-party request you import from accidentally exfiltrating cookies for an unrelated host.
1

Open the Domains allowlist tab

In the Cookie manager, switch to the Domains allowlist tab.
2

Add a host

Type a host (for example api.example.com) into the input and click Add. The host appears in the list below.
3

Revoke when no longer needed

Hover a host in the list and click Revoke to remove it from the allowlist. Scripts can no longer access cookies for that host until you add it back.
The allowlist only governs script access to the jar. Cookies are still captured from responses and attached to requests automatically regardless of whether their host is allowlisted.

​
What’s Next?

Authorization

Configure auth alongside cookies for full session reproduction

Request Headers

Override jar-attached cookies with a manual Cookie header

Scripts

Read and write cookies from pre and post-request scripts