Cookies & sessions

The cookie jar

A collection run shares a single cookie jar. When a response includes Set-Cookie headers, Ironcall parses them and stores the cookies by domain and path. On each subsequent request, cookies that match the request URL are sent automatically in a Cookie header.

This makes session-based flows work without manual wiring: a login request that returns a session cookie is followed by authenticated requests, as long as they run in the same collection run and target a matching domain.

The jar lives for the duration of the run. It is not persisted to disk between runs.

Reading and editing cookies in scripts

Scripts access the jar through ic.cookies, available in both pre-scripts and post-scripts. In a pre-script the jar reflects the cookies that will be sent with the request; in a post-script it also reflects any cookie set by the response.

ic.cookies.get(name)                       // value as string, or null
ic.cookies.all()                           // every cookie as a plain object
ic.cookies.jar()                           // alias for all()
ic.cookies.set(name, value, domain, path)  // add or update a cookie
ic.cookies.delete(name, domain, path)      // remove a cookie

domain and path are optional on set and delete; path defaults to /.

Examples

Read a session cookie set by a previous request:

// Post-script
const session = ic.cookies.get("session_id");
ic.test("session cookie was issued", () => {
  ic.expect(session).not.toBe(null);
});

Seed a cookie before a request runs:

// Pre-script
ic.cookies.set("consent", "all", "example.com", "/");

CLI

The cookie jar behaves the same way under ironcall run. Cookies set during the run are applied to later requests, and the final jar state is included in the JSON reporter output. See the Collection runner and CLI reference.