TokensAPI

Authentication

The x-api-key header, the scope v2 needs, who may write to a list, and how to keep your key safe.

Every endpoint on this page is authenticated with an API key in the x-api-key header (not Authorization: Bearer):

curl -sS "$API_BASE_URL/$PATH" -H "x-api-key: $API_KEY"

A missing key returns 401 with message: "Missing API key"; a key that is not active returns 401 with message: "Invalid API key". A key without the required scope returns 403 with details.required and details.granted.

Scopes and ownership

  • Every v2 endpoint, reads and writes alike, needs only the default assets:read scope. A key with that scope can read every published list, search, resolve, and read every asset, variant and chain.
  • Write endpoints (POST /v2/lists, PATCH and DELETE /v2/lists/{slug}, and the /members routes) act only on lists owned by the caller's project. The key that creates a list binds it to that key's project; every key on the project can manage it, and keys from other projects get 403 on writes. See Token lists → Ownership.
  • The provider lookup budget behind search and batch writes is counted per key, not per project; see Errors & limits.

Keep your key server-side

Treat the key like a password:

  • Call the API from your server or an edge function and proxy the data to the browser. Never ship the key in frontend code or a public repository.
  • Rotate a key from the dashboard if it leaks. Regenerating a key deactivates the previous one immediately.
  • One key per environment (development, staging, production) keeps usage and rate limits separate.

Request ids

Every response carries an x-request-id header. When you report a problem, include the request URL, the response body (with your key redacted), the x-request-id, and the UTC time of the call.