Skip to content

Quickstart

cartonium exposes REST APIs under /api/v1. These are common storefront and merchant integration paths; use the API reference for the complete published surface and each operation's authentication requirements:

SurfacePrefixAuthUse it for
Public/api/v1/public/*Anonymous catalog reads need tenant context; other operations can require checkout tokens or customer credentialsCatalog, collections, pages, and documented checkout calls
Merchant/api/v1/merchant/*Supabase staff JWT; tenant-scoped operations also require the slug headerCatalog, inventory, and order operations with membership/permission checks
Customer/api/v1/customer/*Opaque customer session or purpose-bound action token, per operation, plus tenant contextAccount data and scoped customer actions
Server-to-server storefront/api/v1/storefront/*Server-side only tenant API key; staging implementationBackend catalog/context reads; full API-key productization remains in development

Inbound signed provider callbacks under /api/v1/webhooks/* are outside the published OpenAPI reference; see Webhooks for that boundary. /api/v1/platform/* and internal operations are cartonium-operated surfaces, not tenant storefront integration targets.

1. Identify your tenant

For tenant-scoped catalog reads, send your store's slug in x-organization-slug; no privileged credential is needed. Some operations are org-agnostic or resolve the tenant from a token or key instead. See Tenants & context for those exceptions.

The examples use https://api.preview.litecommerce.io and an enabled tenant Sandbox. Register and verify the test storefront address in Settings → Domains → Sandbox (Preview/Staging), then use that actual address in the public request below. Domains selects the data; the Preview API hostname does not select Sandbox by itself. Sandbox is the in-progress storefront-sandbox capability; use it for staging validation only when the operator confirms the tenant's provisioned test setup. Compare the API/reference schema identity before running examples; see Environments & schema identity.

2. Make a public read

Public catalog reads need tenant context and a registered storefront origin, without a credential. Replace the example origin with the Sandbox address in Domains. Browsers send their own Origin; server transports forward the current request origin. See automatic data selection.

A newly enabled Sandbox starts empty and does not copy the Production catalog. This example requires an ACTIVE item with the shown slug already created in that Sandbox; otherwise expect 404. Substitute an existing ACTIVE Sandbox item's slug:

curl https://api.preview.litecommerce.io/api/v1/public/items/trail-pack-38l \
  -H "x-storefront-origin: https://preview.your-store.example" \
  -H "x-organization-slug: your-store"
{
  "id": "9f2c…",
  "name": "Trail Pack 38L",
  "slug": "trail-pack-38l",
  "type": "SALE",
  "status": "ACTIVE",
  "priceInCents": 18900,
  "compareAtPriceInCents": null,
  "shortDescription": "Lightweight 38L hauler.",
  "description": "…",
  "brand": "Summit",
  "variants": [{ "id": "…", "name": "Granite", "sku": "TP38-GR", "priceInCents": 18900 }],
  "metafields": {}
}

Public reads always return only ACTIVE records — a caller can't request DRAFT or archived items.

The merchant example below creates a draft for authoring; it will remain absent from public reads until it is deliberately activated.

Use shortDescription for compact catalog/card copy. Use description as the primary product detail page body. metafields are for tenant-specific extras that the core schema does not model, not the default home for the main description.

3. Authenticate as merchant staff

Merchant writes require an authenticated staff session — a Supabase Auth JWT in the Authorization header — plus the same x-organization-slug header to scope the request to one of your memberships.

Merchant operations retain authenticated mode selection. The header below selects Sandbox for this staff write; it is not a storefront routing setting.

curl -X POST https://api.preview.litecommerce.io/api/v1/merchant/items \
  -H "Authorization: Bearer <supabase-jwt>" \
  -H "x-commerce-environment: sandbox" \
  -H "x-organization-slug: your-store" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Trail Pack 38L", "slug": "trail-pack-38l", "type": "SALE", "status": "DRAFT", "priceInCents": 18900 }'

This merchant write uses MerchantAuthGuard (validates the JWT), MembershipGuard (confirms tenant membership), and RolesGuard (enforces the operation's role/permission policy). Other operations can have different requirements, including the staff session read before a tenant is selected. See Auth & roles.

4. Handle errors

Every 4xx/5xx response uses one consistent shape, so you can write one error handler for the whole API:

{
  "code": "string",
  "message": "human-readable summary",
  "details": {}
}

See Error envelope for the full contract.

Next steps

  • Read the Concepts section end to end — it's short and it's the fastest way to build a correct integration.
  • Browse the API reference for every endpoint.
  • Generate or vendor the public wire contracts you need, then consume the currently documented cartonium REST APIs from your frontend.