Every Seller API request carries an API token in the Authorization header:
Tokens start with gci_. Create them in the dashboard under Integrations > API; see API tokens for the steps.
A token belongs to one store, so it never needs a store id. Keep tokens on your backend. Never put one in storefront JavaScript, a public repository, a log, or a screenshot.
When authentication fails
Scopes
Each operation declares the scopes it needs, and a token must have all of them. Write scopes never include read access: a token with only orders:write can add a note but cannot list orders. The dashboard checks the read scope for you when you pick a write scope; keep it unless the integration really only writes.
Buyer data
Without orders:buyer:read, responses leave out who bought: no buyer object on orders, and no email or name on the order of a queued command. Filters that search by the buyer need the scope too, because a search can confirm who bought even when the results hide it. On GET /v1/seller/orders that means email, accountIdentifier, and q; on GET /v1/seller/commands it means accountIdentifier.
A queued command is already rendered, so command can contain the buyer’s in-game name or another identifier. commands:read shows it regardless of orders:buyer:read.
Scopes that act
orders:approve approves an order as if the payment had been confirmed. The delivery commands run and the order.payment_approved webhook goes out. Grant it only to systems that confirm payments on their own.
