Admin API

The Admin API is the control plane for Thor Commerce.

Use it to create and maintain the data the storefront runs on:

• stores and channels
• products, variants, categories, and collections
• prices and inventory
• shipping methods, taxes, and payment gateways
• customer groups and discounts

It is a GraphQL API, so reads and writes happen through the same endpoint. Queries help you inspect the current configuration. Mutations change the runtime state the storefront depends on.

Start with the Admin API quickstart, then use the workflow guides before dropping into the generated reference.

The public GraphQL URL includes the project id before the API surface.

Use the project segment in every production request:

• /{project}/admin/graphql for Admin API requests
• /{project}/storefront/graphql for Storefront API requests

At the gateway, Thor resolves that segment and uses it to scope every resolver, permission check, database connection, and downstream service to the correct project. Use the project-specific URL for all requests.

The Admin API supports user access tokens and API keys.

For a signed-in Admin user, send the access token as Authorization: Bearer {{token}}. This preserves the user’s identity and permissions. Operations that need a human identity, including product exports, translation exports, and translation imports, must use this method because they require user ID and email claims.

For server-to-server access, create an API key in the Thor Dashboard and send it as X-Api-Key: {{api-key}}. Do not send an API key as a bearer token. API keys should remain in server-side secret storage and should receive only the permissions the integration needs.

Choose one method per request. Both methods are scoped by the project URL and subject to permission checks.

Thor uses stable typed IDs across the GraphQL APIs. IDs are not base64 Relay IDs; they are Thor type IDs that preserve the underlying resource type, such as product, cart, order, customer, or channel.

Most list fields use cursor pagination. Request edges.node for records and pageInfo for navigation state. Keep cursors opaque: store and pass them back as after or before, but do not parse them.

When you already have an ID and need to refetch the resource generically, use the node(id: ID!) query and select the concrete fields with inline fragments.

Thor uses standard GraphQL error patterns.

Expect errors in two places:

• transport or authentication failures through the HTTP response
• GraphQL execution failures in the top-level errors array

Some mutations also return typed business errors in their payloads or unions. That means a 200 OK response can still contain a failed business operation. Always check both the top-level errors field and the mutation payload you requested.

Thor-specific behavior such as search query syntax and predicate evaluation lives in the Developer guides.