Skip to main content
Every application starts with a primary secret that has full access to everything the application can do. You can add named API keys next to it, one per service or partner, each with only the access it needs. Give your payout provider a key that reads approved sessions of one workflow and can’t change anything, keep a separate key for your backend, and revoke either one without touching the other.
Keys created before scoped access existed keep full access. Nothing changes for them until you edit their access.

​
Where to find them

In the Business Console, select your application and open Developers -> API keys. The list shows every key of the application with its status, its requests over the last 30 days, who created it, its access and when it was last used. Click a key to preview it on the right, or open its full page for usage, access, recent requests, a quickstart snippet and its activity. Keys belong to one application and work only for it. A key has the application’s environment: keys of a sandbox application never create billed verifications.

​
Create a key

1

Detail

Name the key after the service that will use it, and choose when it expires: never, in 30 days, 90 days, a year, or on a date you pick. An expired key stops working at the end of that day, UTC.
2

Access

Start from a preset, then fine-tune it per resource. The key can never do more than this.
3

Review

The console spells out what the key can do and what it can’t, before you hand it out.
4

Secret key

Copy the secret and store it in your secrets manager. This is the only time the full secret is shown. If you lose it, rotate the key to get a new one.

​
Presets

​
Resources

Read covers GET requests on a resource; write also covers POST, PUT, PATCH and DELETE. A key with custom access works on the public API: the session, user, business, transaction, workflow and webhook endpoints, and the standalone checks. Endpoints that only the Business Console uses answer 403 to it; they need a full-access key. A key without Media read receives session decisions with every image, video and PDF URL set to null, and PDF report endpoints answer 403. A key without Sessions write never receives a session’s verification link or session token, since whoever holds them can complete the verification as the end user: those fields come back as null.

​
Limits

A key limited to some workflows or to approved sessions works on the session endpoints, where the limit can be applied. It can’t have access to people, companies, transactions or analytics, and it can’t run standalone checks.

​
How the API answers a scoped key

Session lists only return the sessions the key’s limits allow.

​
Edit access

Open a key’s menu, its preview or its page and choose Edit access. Change the preset, resources, limits or expiry, then review only what changes, before and after. The secret stays the same, so nothing needs redeploying, and the new access applies within a minute. The primary secret always has full access and can’t be edited.

​
Rotate a key

Rotating replaces a key’s secret. The new secret is shown once, and the current secret keeps working for 24 hours so you can deploy the new one without downtime. After that, every request with the old secret answers 401. The primary secret is rotated the same way, with the same 24-hour overlap.

​
Revoke a key

Revoking stops a key at once: every request made with it answers 401. It cannot be undone. The primary secret can’t be revoked; rotate it instead.

​
Usage and audit trail

Each key shows its requests over the last 30 days, its error rate and latency, and its latest requests with their status codes, including the ones its limits refused. Every call made with an API key appears in the organization’s audit logs with the name of the key that made it.

​
Who can manage keys

Managing API keys needs the API keys permission: read to see them, write to create, edit, rotate and revoke them. See Roles and permissions.