Skip to main content
A rate limit on a key counts that key alone. If a user has three keys at 100 requests per minute each, they can make 300. Put the limit on the user’s identity instead, and all their keys share the same 100. Here’s how to set it up.
You need a root key with the permissions listed on this page. Create one in the dashboard under Settings > Root Keys, and pass it as Authorization: Bearer <root key>. See Permission reference for every permission.
The root key needs identity.*.create_identity (or identity.*.update_identity for an existing identity), api.*.create_key, and api.*.verify_key.
1

Create the identity with a limit

autoApply: true makes the limit count on every verification without the caller naming it.
If the identity already exists, for example because a key was created with this externalId earlier, the call returns HTTP 409 err:unkey:data:identity_already_exists. Use identities.updateIdentity with the same ratelimits array instead.
2

Create keys that belong to it

Any key created with the same externalId is linked to the identity.
3

Verify any of the keys

The identity limit is auto-applied, so a plain verification enforces it. Requests through the production key and the staging key both draw down the same 100 per minute.
data.ratelimits shows the limits that were checked, with remaining and reset.

Several limits on one identity

Add more than one limit when different operations need different budgets. A limit with autoApply: false is only checked when a verification names it, so an expensive endpoint can have its own budget.
Then spend 150 tokens on one call:
Both requests (auto-applied) and tokens are checked together. If either is exceeded, the verification returns RATE_LIMITED and neither is consumed.

Exceptions for one key

If a key has a limit with the same name as one on its identity, the key’s limit wins for that key. Use this to give one integration a higher limit than the user’s other keys. Details are in Key and identity rate limits.
Last modified on September 29, 2026