QA The Other WayQuality assurance for the age of AI-written tests. QA The Other Way.
Practical QA

Your API check may share the browser cookie jar.

Choose shared or isolated request state deliberately before treating an API result as independent evidence.

5 min readQA The Other Way
An authored shared cookie jar beside a separate isolated request jar.
Authored editorial illustration.
Illustrative video for this article. English on-screen text; select subtitles for this language.
Choose shared or isolated request state deliberately before treating an API result as independent evidence.
Illustrative local specimen with invented data, not a customer or vendor interface.

A test opens a signed-in page and then calls an API to inspect its result. The engineer assumes the request has a separate identity because it did not run through a button. In Playwright, the request context attached to the browser can share its cookies. An API call is not automatically an independent authentication boundary.

This guide uses the APIRequestContext documentation with a local server and an invented cookie called demo_session. There is no real credential or account. We show which cookie jar is used, not how to bypass a product's access rules.

Identify which request context you created

The documentation says browserContext.request and page.request share cookie storage with their browser context. Requests use those cookies, and response cookies can update that storage. This is useful for a journey that deliberately keeps the same test session, but it matters when interpreting evidence.

A separate context created through request.newContext has its own cookie storage. Choose it when the case requires independent request state. Isolation is a setup choice, not a label added after the response happens to match.

const shared = await page.request.get('http://localhost:4181/who');
expect(await shared.text()).toBe('demo_session=fixture');

const isolated = await request.newContext();
try {
  const response = await isolated.get('http://localhost:4181/who');
  expect(await response.text()).toBe('no demo cookie');
} finally {
  await isolated.dispose();
}

The snippet assumes the local server and a browser context already carrying the invented fixture cookie. Import request and expect from Playwright's test package. The server reports only the controlled cookie for this demonstration. Never echo real session headers into public test artifacts.

Decide what independence means

A shared request can inspect a server result through another path while still using the same identity. That can be a useful independent outcome check, but it is not a check from another user or an anonymous client. Name the layer that is independent: read path, identity, storage or authorization expectation.

An isolated request context without a cookie tests a different setup. It does not prove a real logged-out policy unless the product's supported endpoint and expected response are also established. Our server merely returns an invented string, so its result cannot certify production access control.

Explicit state can be copied into another context, but that would change its meaning. Do not describe a context initialized with the same session as anonymous. Likewise, an empty cookie jar may still receive configured headers or other credentials. Inspect the complete request setup.

Keep response effects visible

Cookie sharing works in both directions according to the API guide. A response that sets a cookie through the shared request context can affect later browser behavior. A setup request may therefore change more than a server record.

The local test checks this deliberately: a shared response sets a second invented cookie, then the browser context reports it. The isolated context remains separate. This is a mechanism check, not a claim about every application's session design.

Close disposable request contexts when finished. The documentation describes retaining response bodies for later reading and disposing resources when no longer needed. Cleanup should preserve the evidence you intend to read before removing the context.

Write the identity boundary in the test note

Record which request object is used, its initial state, any response cookie effects and the expected identity. Use approved staging sessions and avoid publishing storage-state files or response headers containing access data.

AnyTest describes agents exploring web apps and producing tests for human review. Ask whether an API check shares the journey's session or deliberately uses separate state. No particular AnyTest request-context implementation is claimed. Independence must name the boundary, not merely the transport.

Common questions

Does page.request use a separate cookie jar?

No. It shares cookie storage with the associated browser context.

Does an isolated context automatically prove anonymous access policy?

No. Its complete setup and the real endpoint expectations must be established.

Sources