> ## 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. # Cookies > Manage cookies for your API requests in Requestly. Cookies captured from responses are stored in a shared cookie jar and automatically attached to matching outgoing requests. 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. ## Open the Cookie manager The **Cookies** button is in the application footer at the bottom of the window. Clicking it opens the **Cookie manager** modal. 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. ## Add a cookie manually 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. 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. 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. 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. ## Find a cookie quickly 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. ## Cookie row indicators 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. In the **Cookie manager**, switch to the **Domains allowlist** tab. Type a host (for example `api.example.com`) into the input and click **Add**. The host appears in the list below. 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? Configure auth alongside cookies for full session reproduction Override jar-attached cookies with a manual `Cookie` header Read and write cookies from pre and post-request scripts