Share Authentication Cookies Between Playwright API and Browser Contexts

API login can remove slow UI setup from a Playwright test, but only when the resulting cookies enter the browser context that will open the application. The phrase "request context" hides an important distinction: a request object associated with a browser context shares its cookie jar, while a standalone API request context owns an isolated jar.

Choose one transfer path and make it obvious in code. Either log in through context.request and continue in that same browser context, or authenticate through an isolated API context, export storageState, and construct a browser context from it. Most mysterious logged-out pages come from mixing those two models.

Understand Which Object Owns the Cookie Jar

Every browser context has an associated APIRequestContext, available as browserContext.request and through a page as page.request. According to the APIRequestContext documentation, those requests populate their Cookie header from the browser context and update browser cookies from Set-Cookie responses.

A standalone request context has separate storage. That isolation is useful for setup, direct API tests, and creating state for a future context. It does not mutate an existing page. The transfer must happen through a storageState object or file.

Pattern One: Log In Through the Browser Context Request

Use the context-associated request object when the test already has a browser context and the API can set its session cookie. The browser page does not need to visit the login form; its jar is updated before navigation.

import { expect, test } from "@playwright/test";

test("opens the dashboard after API login", async ({ context, page }) => {
  const response = await context.request.post("/api/auth/login", {
    data: {
      email: process.env.E2E_USER_EMAIL,
      password: process.env.E2E_USER_PASSWORD,
    },
  });

  expect(response.ok()).toBeTruthy();

  const cookies = await context.cookies();
  expect(cookies.some((cookie) => cookie.name === "session")).toBeTruthy();

  await page.goto("/dashboard");
  await expect(page.getByTestId("account-menu")).toContainText("QA User");
  await expect(page).toHaveURL(/\/dashboard$/);
});

Validate credentials before constructing the request rather than allowing undefined into the payload. The cookie-name assertion is diagnostic; the protected UI is the behavioral proof. Do not log the cookie value or attach it to a report.

This pattern also works in the opposite direction. After UI login, page.request.get("/api/me") carries the browser context's cookies. It is useful for verifying server state or preparing data as the same identity, but avoid turning every UI assertion into a direct API shortcut.

Pattern Two: Export an Isolated Request State

Use an isolated request fixture or context when authentication is part of reusable setup or when no browser context should exist yet. After login, capture state and pass the object into browser.newContext().

import { expect, test } from "@playwright/test";

test("transfers an API session into a new browser context", async ({
  browser,
  request,
}) => {
  const response = await request.post("/api/auth/login", {
    data: {
      email: process.env.E2E_USER_EMAIL,
      password: process.env.E2E_USER_PASSWORD,
    },
  });
  expect(response.status()).toBe(204);

  const storageState = await request.storageState();
  const authenticatedContext = await browser.newContext({ storageState });

  try {
    const page = await authenticatedContext.newPage();
    await page.goto("https://app.example.test/dashboard");
    await expect(page.getByRole("heading", { name: "Dashboard" })).toBeVisible();
    await expect(page.getByRole("link", { name: "Sign in" })).toHaveCount(0);
  } finally {
    await authenticatedContext.close();
  }
});

The request fixture remains isolated from the default page. Creating a new browser context is the explicit handoff. For suite-wide setup, write state to an ignored path and configure a project to load it; for a single test, an in-memory object avoids leaving a credential artifact on disk.

Check Domain, Path, Scheme, and SameSite

A cookie is not a portable key-value pair. Its domain and path decide which requests receive it. If login occurs at api.example.test and the server creates a host-only cookie, that cookie will not be sent to app.example.test. The authentication service must intentionally set a domain compatible with the application architecture, or the browser must navigate on the cookie's valid host.

Secure cookies require HTTPS, except for browser-specific local development allowances that should not be assumed. A cookie scoped to /api will not accompany a document request to /dashboard, although later API calls may still include it. SameSite policy influences cross-site requests and redirects. Verify the product's intended cookie settings rather than editing state JSON to force a test pass.

Inspect metadata safely:

const session = (await context.cookies()).find(
  (cookie) => cookie.name === "session",
);

expect(session).toMatchObject({
  httpOnly: true,
  secure: true,
  sameSite: "Lax",
});
expect(session?.domain).toBe(".example.test");

Attribute expectations must match the security design. Do not copy this exact domain or SameSite value into a different architecture without reviewing its cross-site login and embedding requirements.

Distinguish Cookies From Token Responses

Some login endpoints return an access token in JSON and set no cookie. A successful status then leaves the request jar unchanged. Decide whether the web application normally converts that token into a cookie, stores it in browser storage, or keeps it in memory. The test should use the same supported boundary as the application.

Do not invent a cookie from the JSON token unless that is the documented client behavior. Doing so bypasses cookie attributes, session establishment, and CSRF controls. If the app stores authentication in local storage, storageState can carry origin storage after it has been populated, but an API request alone cannot guess the browser-side key and initialization sequence.

Authentication that relies on IndexedDB needs explicit handling in the storage capture path. Confirm what the application actually reads at startup, then assert the resulting identity. "API login succeeded" and "browser session was established" are separate checkpoints.

Use the Shared Jar for Authenticated API Setup

Once the browser context is authenticated, its request object can create data that belongs to the same user. This avoids a second token mechanism and ensures tenant or role cookies remain consistent. Check API responses before navigating so a failed setup does not masquerade as an empty-page defect.

Keep mutation ownership clear. If a test creates a project through context.request, store its ID and delete it through a privileged cleanup fixture even when the UI assertion fails. Parallel tests need unique records or worker-owned accounts. Cookie sharing solves identity transfer; it does not solve backend data collisions.

For role-based scenarios, create distinct contexts and request jars. Never replace the cookies in one shared context to switch from member to admin midway through a test. Separate contexts preserve isolation and make every API call attributable to one actor.

Diagnose Cookie-Sharing Failures

If response.ok() is true but context.cookies() is empty, inspect whether the endpoint returned Set-Cookie or only JSON. If cookies exist but the page redirects, compare their domain, path, expiry, and secure flag with the navigation URL. Also verify that the API and browser contexts target the same environment.

If a standalone request logs in successfully while the default page remains anonymous, state was never transferred. Export it and create a context, or move login to context.request. If authentication disappears only in parallel, the server may invalidate older sessions when the same account logs in again. Allocate accounts per worker or use a session policy designed for concurrent automation.

Redirects can set the final cookie late in the flow. Wait for the API request to complete its redirect chain and inspect the jar afterward. Avoid manually parsing a combined Set-Cookie header when Playwright can maintain the structured cookie jar for you.

Choose Shared Context or Explicit Handoff

The shared context request is concise and ideal for per-test login or authenticated data setup. Its coupling is also its risk: an API helper can silently modify browser identity. An isolated request plus storageState makes the transfer visible and supports reusable setup, but introduces lifecycle and secret-artifact concerns.

Prefer shared context requests for a test that owns one identity from start to finish. Prefer isolated setup when creating a state before projects run or provisioning several roles. In both cases, keep the identity and destination environment explicit.

Operational Checklist

• Identify whether the request object shares or owns an isolated cookie jar.
• Assert the login response before opening the protected page.
• Transfer isolated API state explicitly into a new browser context.
• Verify cookie name and metadata without exposing its value.
• Check domain, path, Secure, SameSite, and expiry against the page URL.
• Confirm whether the endpoint sets cookies or returns a token body.
• Keep saved storage state ignored and access-controlled.
• Use one context per role instead of swapping credentials in place.
• Clean up API-created records with IDs owned by the test.
• Allocate distinct accounts when parallel logins invalidate sessions.

Action Plan

Pick the simpler of the two cookie paths for the current suite and remove any ambiguous helper that mixes them. Add a response assertion, a non-secret cookie metadata check, and one protected UI assertion. Run the test once with an intentionally wrong application host to confirm the domain failure is understandable. Then move reusable state to an ignored setup artifact or keep single-test state in memory. The result should make cookie ownership visible from login call to final page.