Skip to main content
The Infinity API authenticates every request with a secret API key, sent as a bearer token. A key belongs to one account and one environment, and it carries the full permissions of that account, so handle it with the same care as a database password.
Send the key in the Authorization header on every request, over HTTPS. The API doesn’t accept keys in query parameters, where they end up in access logs and browser history, or through HTTP Basic auth. A request without a valid key fails with 401 before any work is done.

Environments

The key’s prefix selects the environment, and each environment has its own host, data and keys. Infinity checks the prefix against the host before it looks up the key. A test key sent to the live host, or a live key sent to the sandbox, fails with 401 wrong_environment. This means a misconfigured deployment fails loudly on its first request instead of moving real funds from a test suite, or test traffic into production. IDs are also environment-specific: an object created in the sandbox can’t be read with a live key, and the other way round.

Obtaining keys

Sandbox keys Sandbox keys are issued by our team. Contact us with your company name and we’ll set up your sandbox account and send you an sk_test_ key. Live keys Create live keys on the Developers page of the dashboard. Your Infinity team can also issue your first live key during onboarding. A key is displayed once, when it’s created. Infinity stores only a SHA-256 fingerprint of the key and its first 12 characters (for example sk_live_7kq9), which the dashboard shows so you can tell keys apart. A lost key can’t be recovered; create a new one and revoke the old one.

Key format

A key is the environment prefix followed by 32 random characters from a 31-character alphabet, roughly 158 bits of entropy:
Treat the whole string as opaque. Don’t parse it beyond the prefix, and allow for at least 64 characters wherever you store it.

Permissions and limits

  • Every key has full access to its account’s API. Scoped and read-only keys aren’t available yet, so isolate risk by giving each service or deployment its own key.
  • An account can hold up to 5 active keys. Revoked keys stay listed for audit and don’t count toward the limit.
  • API keys can’t create, list or revoke keys. Key management is done on the dashboard, signed in as a person, so a leaked key can’t be used to mint new ones.

Storing keys

  • Keep keys out of source control. Load them from your platform’s secrets manager, or from environment variables where no secrets manager exists.
  • Never embed a secret key in a browser, mobile or desktop app. Anything shipped to a client can be extracted.
  • Scrub the Authorization header from request logs, error trackers and APM traces.

Rotation

Because an account can hold several active keys, you can rotate without downtime:
  1. Create a new key and deploy it alongside the old one.
  2. Watch the old key’s last used time on the dashboard. It updates at most once a minute.
  3. When the old key has stopped being used, revoke it.
Revocation takes effect immediately: the next request with a revoked key fails with 401 invalid_api_key. If you suspect a key has leaked, revoke it first and investigate afterwards, then tell your Infinity contact.

Errors

All errors use the standard error body; see Errors.