Skip to main content
Every Studio API request needs a studio API key. Keys are created in the store UI, never over the API itself.

​
Creating a key

  1. Open your studio’s dashboard and go to Settings → API.
  2. Click New key, give it a recognisable name (e.g. “Discord bot”), and pick a tier:
    • Basic, free. Reads your studio profile, products, and version history.
    • Premium, requires an active Branding+ subscription. Everything in Basic, plus sales, revenue summaries, timeseries, and top products.
  3. Copy the key immediately. It is shown exactly once, only a hash is stored on our side.
A key looks like:
Managing keys requires the Manage settings permission on the studio (owners always have it). A studio can have at most 10 active keys.

​
Sending the key

Use the x-api-key header (recommended):
Or as a bearer token:

​
Key tiers and the live subscription check

The tier is a property of the key, chosen at creation:
  • A basic key never gets premium access, even while the studio is subscribed. This lets you hand a basic key to a third-party integration without exposing your sales data.
  • A premium key works on premium endpoints only while the studio’s Branding+ subscription is currently active. The subscription is verified live on every request; if it ends, premium endpoints respond with 403 SUBSCRIPTION_INACTIVE until the plan is renewed. Free endpoints keep working with the same key throughout.

​
Scope and isolation

  • A studio key identifies the studio, not the member who created it. It only works on …/public/v1/studio/* endpoints and can only read its own studio’s data.
  • Studio keys are rejected everywhere else on the public API (401 STUDIO_KEY_NOT_ALLOWED), and personal keys (nmk_live_…) are rejected on studio endpoints (401 STUDIO_KEY_REQUIRED).
  • Browser sessions are not accepted on studio endpoints.

​
Revoking a key

Revoke a key any time from Settings → API. Revocation takes effect immediately: the next request with that key returns 401 REVOKED_API_KEY. Revocation cannot be undone, create a new key instead.
Treat keys like passwords. Don’t commit them to git, don’t ship them in client-side code, and revoke any key you suspect has leaked.