API Keys & Secrets

An API key is the identity your app presents to the gateway. It pairs a public key id with a private secret, and it is bound to your account — a key can only ever act as itself.

This page is the concept. To actually issue one, see Get & Manage Keys — you create your own from your panel.

Key id and secret

	Key id	Secret
Sent on requests?	Yes, as `x-key-id`.	Yes, as `x-api-secret`.
Format	`ak_<env>_<64 hex>`	128 hex characters.
Retrievable?	Always.	Shown once, when the key is issued or rotated. Not readable again through the panel or the API.

The secret is what proves a request is yours — see Authentication.

Treat it like a password: store it in a secret manager, never commit it, never put it in client-side code. Because it travels on every request, prefer keys restricted with an IP allowlist in production.

There is no "reveal secret" feature, in the panel or the API, by design — the gateway keeps only an encrypted copy it can verify a request against, so the product has nothing to show you and no support request can read it back out. If a secret is lost or leaked, rotate the key; that is the only recovery.

Environments

The key id prefix records which environment the key was issued for:

ak_live_… — production keys.
ak_test_… — non-production keys.

Use test keys in development and CI, and live keys only in production.

The prefix is a label, not a billing guarantee. ak_test_ does not by itself mean a sandbox, a simulated provider, or a free request — whether an environment reaches real providers and spends real balance is a property of that environment, and only your provider can tell you which yours does. Confirm the environment, its billing and its base URL with them before your first paid call; see Environments and billing.

What a key carries

Each key is issued with a fixed set of properties:

Property	Meaning
Account	The account the key acts on behalf of. A key can never act on another account.
IP allowlist	Optional. If set, requests from any other address are rejected.
Rate limit	Requests allowed per window — see Rate Limits.
Status	`active` or `revoked`. A revoked key fails immediately.

Which products and operations a key may call is set when it is issued. If a call you expect to work returns 401 INVALID_API_KEY while your credentials are definitely correct, that is the thing to check with whoever issued the key — quote the requestId from the response and it can be confirmed exactly.

Lifecycle

	What happens
Create	The key is issued and the secret is shown once. Capture it then.
Rotate	A replacement key id and secret are issued, and the old key is revoked. Use this on any suspected leak, or on a schedule.
Revoke	The key is permanently disabled and fails authentication at once.

Rotation issues a new key id, not just a new secret, so update both x-key-id and the secret together. There is no overlap: the old key stops working the instant the new one is issued, so calls using it fail until your deployment ships the new pair. To change credentials with no failing requests, issue a second key and revoke the first once traffic has moved — see Get & Manage Keys.

Using more than one key

Prefer one key per integration. Separate keys make revoking or rotating one system surgical, instead of an outage for everything that shared a credential.

Note that extra keys do not buy extra throughput: rate limits are counted per account, not per key — every key on your account spends from one allowance.