Skip to main content
Every request needs your API key, sent as a Bearer token:
If a Bearer token doesn’t suit your setup, you can send the key in an X-Api-Key header instead. Either one works.

​
Live and test keys

A key that starts with sk_live_ works against your real workspace. One that starts with sk_test_ belongs to a sandbox — a free, isolated copy for building and testing, where nothing touches real data or real money. The key decides which one you reach, so the same base URL and the same code work for both. The first part of the key — the bit you can see in the dashboard — is just there to help you tell keys apart. The rest is the secret, and you only see it once, when you create the key.

​
The key already knows your workspace

A key belongs to one workspace, and that’s how we know whose data you’re asking for. It’s why the workspace never shows up in the URL: GET /v1/products returns the products for whatever workspace the key belongs to.

​
Keep your keys safe

Treat a key like a password:
  • Keep it on your server — never in a browser, a mobile app, or a public repo.
  • Always call the API over HTTPS.
  • To rotate a key, create a new one and delete the old one. Deleting takes effect right away and can’t be undone.
  • Give each key only the permissions it needs (see Scopes & permissions).

​
When sign-in fails

  • 401 — the key is missing, wrong, or no longer active.
  • 403 insufficient_scope — the key is valid but isn’t allowed to do this.
  • 403 plan_required — the workspace’s plan doesn’t include the API. (Live keys only — sandboxes are free.)
Errors shows exactly what these responses look like.