Skip to main content
The Admin API supports two authentication methods. Both reach the same endpoints — they differ in where the credential lives and how authorization is decided:

Secret API key (server-to-server)

Create a secret key in the admin under Settings → API Keys, grant it the scopes your integration needs, and pass it to the client:
Each key carries the list of scopes granted at creation time. A request to an endpoint the key isn’t scoped for fails with code: 'access_denied' — the error’s details.required_scope names the missing scope (see Querying & Errors).
Secret keys grant back-office access to your store. Never embed them in client-side code, mobile apps, or public repositories — keep them in server-side environment variables or a secrets manager.
For browser-based admin tooling, authenticate as an admin user. The flow is designed so that no long-lived credential is ever exposed to JavaScript:
  • auth.login() returns { token, user } — a short-lived access token you hold in memory.
  • The refresh token never appears in JSON. The server sets it as an HttpOnly cookie scoped to /api/v3/admin/auth, and the SDK sends requests with credentials: 'include' by default, so the cookie flows automatically.
  • auth.refresh() takes no arguments — it’s driven entirely by the cookie, and rotates it on every call.
  • auth.logout() revokes the refresh token server-side and clears the cookie.

Bootstrapping a returning session

Because the refresh cookie outlives the in-memory access token, a returning user can be signed back in without re-entering credentials — call refresh() on app load and treat failure as “not signed in”:

Identity providers

auth.login() also accepts third-party identity-provider payloads when the server has a matching strategy registered:

Current user and permissions

After signing in, client.me.get() returns the admin user’s profile together with their serialized permissions — use it to drive what your UI shows:

Staff invitations

The auth resource also exposes the unauthenticated invitation-acceptance flow used when onboarding new staff: auth.lookupInvitation(id, token) returns the safe-to-render invitation context (store, role, inviter), and auth.acceptInvitation(id, token, params) accepts it — issuing a JWT and refresh cookie identical to login. Sending invitations is an authenticated operation on client.invitations.

Custom fetch

Pass a custom fetch implementation when you need request interception, proxying, or a non-standard runtime: