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.

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.

Authenticate every request with an Admin API key from the Thor Dashboard.

Send the key in the X-Api-Key header. Admin credentials should stay server-side. They are intended for backend services, internal tools, migration jobs, and operational scripts, not for public clients.

If the key is missing, invalid, or does not have access to the project, the request fails before any resolver logic runs.

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.

Admin rate limiting is exposed as GraphQL query cost metadata.

Responses can include an extensions.cost object that tells you:

• how expensive the request was
• how much budget is still available
• how quickly budget is restored

When you are building sync jobs, imports, or dashboard tooling, watch that metadata and slow down when the available budget drops. Do not fire high-cost mutations in parallel without backoff.

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 Concepts.