Authentication & Network

If your app requires signing in, capturing pages without credentials produces snapshots of the login screen instead of the views you want to test. The suite settings let you inject authentication data into every page visit.

Available settings

All three are lists in the suite settings and can be scoped per snapshot:

  • Request header - sent with every request, e.g. Authorization=Bearer <token>. Best for APIs and apps with header-based auth.
  • Cookie - set before the page is visited, e.g. session=abc123; Path=/; Secure; HttpOnly. Best for classic session-cookie logins.
  • Local storage key - set before the page loads, e.g. access_token=<jwt>. Best for SPAs that keep tokens in localStorage.

Pick the mechanism your app actually uses - typically one of the three is enough to make the crawler and renderers see the same authenticated views your users do.

Warning
Use dedicated test credentials with minimal permissions. Values stored in suite settings are applied on every run, and snapshots of authenticated views may expose whatever data the test account can see.

Scriptless captures

The bdy tests capture command takes the same values from the command line, optionally scoped to a domain:

bash
bdy tests capture --urls "https://app.example.com/dashboard" \ --header "Authorization=Bearer token" \ --cookie "example.com::session=abc123; Path=/; Secure; HttpOnly" $$$

E2E sessions

When snapshots come from E2E tests, your tests handle the login themselves - the plugin captures whatever state the browser is in when takeSnap is called. The suite-level settings above matter mainly for resources fetched during rendering (fonts, images, API-driven widgets) that need credentials of their own.

Last modified on Jul 13, 2026