keys.verifyKey with no extra call, and users on a higher plan get a higher limit without a code change.
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.Put the limit on the identity
A limit on a key applies to that key alone. A limit on an identity is shared by all the user’s keys. Create the identity with the limit, then create keys with the sameexternalId, and they’re linked automatically. autoApply: true checks the limit on every verification.
The root key needs identity.*.create_identity for the first call, and api.*.create_key or api.<apiId>.create_key for the second.
create the identity
create a key for that user
keys.verifyKey returns code: RATE_LIMITED when the shared limit is used up, and data.ratelimits has remaining and reset so you can send X-RateLimit-* headers.
verify and forward limit headers
identities.updateIdentity with a new ratelimits array (needs identity.*.update_identity). It replaces the whole list, so send every limit the user should keep. All their keys pick up the change within about 10 seconds.
Alternative: the standalone ratelimit API
If you’re limiting something other than a key holder (a logged-in session, an IP address, a tenant), useratelimit.limit. The namespace names what you’re limiting, the identifier is the user, and you send the limit with each request. The response is always HTTP 200, so read data.success.
data.overrideId in the response shows when an override applied. The root key needs ratelimit.*.limit to check limits and ratelimit.*.set_override to create overrides.
give one user a higher limit
Related
- Creating keys for the
externalIdandratelimitsfields. - Verifying keys for the
ratelimitsresponse entries. - Identities, standalone rate limiting, and overrides are documented under API Management.