Skip to main content

Ephemeral vs. Session mode

By default, each fetch() call runs in ephemeral mode. This is a good fit for one-off requests. For multi-step flows (like login sequences), use sessions to persist state.

Creating a session

Auto-disposing sessions

Use withSession() to automatically close the session when done:

Session options

Sessions accept browser, os, proxy, timeout, insecure, and defaultHeaders:

Per-request overrides

Within a session, browser, os, and proxy are fixed at creation time unless you pass an explicit transport for that request. You can still override per-request values like timeout, headers, redirect, and body:
Sessions automatically handle cookies across requests, but you can also read and write cookies directly.

Reading cookies

Use getCookies(url) to inspect which cookies would be sent to a URL:
Use getAllCookies() when you want to inspect the entire session jar without already knowing the matching domain/path:
If available, each entry also includes scope metadata such as domain, path, sameSite, and expiresAtMs.

Setting cookies manually

Use setCookie(name, value, url) to inject a cookie into the session jar:

Saving and restoring a jar

Use setCookies(cookies, url) to put an exported jar back, attributes and all — the way to persist a logged-in session between runs:
The url scopes cookies that have no domain of their own. Those are host-only cookies, and the jar keeps their host internally rather than returning it, so the export cannot carry it. If the jar holds host-only cookies from more than one host, give each cookie its own url instead:

Clearing cookies

Use clearCookies() to remove all cookies from the session:

Session isolation

Each session maintains its own:
  1. Cookie jar: cookies are not shared between sessions
  2. Session identifier and defaults
If you want separate cookie jars but shared transport settings (for example, multiple sessions through the same proxy), use a shared Transport per request.

Best practices

Always close sessions

Call session.close() or use withSession() to prevent resource leaks.

One session per flow

Use a dedicated session for each logical user flow or task.

Parallel isolation

For parallel scraping, create separate sessions to avoid cookie cross-contamination.

Reuse for workflow consistency

Sessions keep one context for multi-step flows.