Authentication and project routing

Every commerce request belongs to a project and an API surface. Authentication determines what the caller can do there. Keeping those boundaries explicit prevents accidental use of a privileged credential in a buyer-facing application.

Admin access

An Admin API key is sent in X-Api-Key from trusted server code. An Admin user access token uses Authorization: Bearer. An embedded app obtains its authenticated Admin client through the app authentication helper. These mechanisms have different permission and session contexts.

Use the least permissions your integration needs. An authenticated request can still fail because it lacks permission for a particular operation. Some import and export workflows require an Admin user session; follow the operation’s documented authentication requirement.

Storefront access and customer identity

A protected project requires X-Thor-Storefront-Token for Storefront access. A public Storefront configuration can allow anonymous requests. This access is separate from the customer’s bearer token.

A customer access token identifies the signed-in buyer and can affect customer-sensitive data and prices. Do not accept a customer ID or group supplied by the browser as proof of identity. Use the authenticated customer response and the supported account workflow.

Application boundaries

Keep Admin credentials and app client secrets on the server. Keep customer tokens out of URLs, logs, and shared caches. Use separate configuration for development and production, including resource IDs.

Connect to a project contains the endpoint and header setup. Add customer accounts covers customer sessions. App authentication and sessions covers embedded apps.