How Thor fits together

Thor Commerce exposes one commerce project through two GraphQL APIs. The Admin API manages configuration and business data. The Storefront API resolves the buyer-facing catalog, cart, checkout, and customer experience from that configuration.

Projects are the isolation boundary

Every request is routed to a project by the project slug in the endpoint:

Stores, channels, products, customers, orders, and settings belong to that project. IDs are meaningful only inside the project that issued them. Keep the project slug and credentials together in configuration, and use separate credentials for separate environments.

Choose the API by responsibility

Use the Admin API from trusted services to create and maintain catalog data, prices, inventory, shipping, payment gateways, customers, orders, and integrations. Authenticate with an Admin user token or an API key as described in the Admin API quickstart.

Use the Storefront API for buyer-facing reads and checkout mutations. Public projects can accept anonymous Storefront requests; protected projects require a storefront token. A customer access token adds customer identity but does not replace project-level Storefront access. See Customer authentication.

Never expose Admin credentials in browser or mobile code.

Resources form a commerce graph

Thor resources are intentionally connected rather than self-contained:

  • A store selects distribution, price, and supply channels.
  • Products and variants are published through distribution channels.
  • Prices can be scoped by price channel, country, customer group, and time.
  • Inventory entries connect a variant SKU to a supply channel.
  • Carts preserve store, currency, price channel, customer, address, and line-item context.
  • Completing a cart creates an order whose totals and line data are retained for order processing.

This is why a product can exist in the Admin API but not appear, have a price, or be purchasable in a particular Storefront request. Start with Stores and channels and Catalog visibility when configuring a new market.

Stores and channels are configuration. Store, currency, country, locale, price channel, and customer identity form runtime context. The same configured product can therefore resolve differently for two requests without becoming two products.

IDs and timestamps

Resource IDs are opaque, typed values. Pass them unchanged and do not derive business meaning from their text. Thor can decode supported IDs through the API when debugging; see Typed IDs.

Where a resource exposes createdAt or lastModifiedAt, treat those timestamps as server-owned. For synchronization, combine stable source identifiers in metadata with cursor pagination and webhooks instead of assuming timestamps alone provide a complete change feed.

Read and mutation patterns

Collection fields use cursor connections with nodes or edges and pageInfo. See Pagination.

Mutations return a typed payload. Request the changed resource and every available error interface or union member your client can act on. A successful HTTP response does not by itself mean the business operation succeeded. See Errors and retries.

  1. Run the Admin API quickstart.
  2. Configure stores and channels.
  3. Model products and variants, then add prices and inventory.
  4. Run the Storefront API quickstart.
  5. Build the cart and checkout flow.