Skip to main content
Every emulator takes the credential its vendor’s SDK already sends: a bearer token, an API key, HTTP Basic, a signed request, or an OAuth access token from the emulator’s own sign-in flow. Your SDK keeps its auth code. Only the base URL changes.

​
Tokens from the config file

The top-level tokens map is shared by every service. Each token names a user, and providers that check scopes read them from here:
With no tokens in the config, the CLI seeds test_token_admin (login admin). Send a token as Authorization: Bearer <token> or Authorization: token <token>, unless the provider’s SDK uses another header (the table below lists those).

​
Any token works from the CLI

When the CLI starts a service, a non-empty token it does not know acts as that service’s default user, so a placeholder such as sk_test_baseline or xoxb-local works with no setup. Credentials the emulator issued itself (OAuth access tokens, API keys created through the API, seeded keys with scopes) are checked the way the vendor checks them: a revoked, expired, or under-scoped one is refused with the vendor’s error. To make a provider strict, seed its own credentials (for example Square’s tokens[] with scopes, HubSpot’s private_apps, or SendGrid’s api_keys). Some providers also take strict_scopes: true (Google, Slack, Linear). Each provider’s page lists its options.

​
OAuth and OIDC

Providers with a sign-in flow serve it locally: the authorization page with a user picker, the token endpoint, and, for OIDC providers, /.well-known/openid-configuration and a JWKS. Register OAuth clients in the provider’s seed config for strict client_id, secret, and redirect URI checks. ID tokens are signed with a key generated per run unless you pin one; see OIDC signing keys.

​
By provider