Skip to main content
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 or checkoutFields 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.
Every approval, cancellation, refund mark, identifier correction, and command resend made with a token leaves a note on the order that names the token. Name each token after the system that uses it so those notes stay readable.