Skip to main content

Get ratelimit override

Retrieve the configuration of a specific rate limit override by its identifier.

Use this to inspect override configurations, audit rate limiting policies, or debug rate limiting behavior.

Important: The identifier must match exactly as specified when creating the override, including wildcard patterns.

Permissions: Requires ratelimit.*.read_override or ratelimit.<namespace_id>.read_override

1 min read
post/v2/ratelimit.getOverride
Request example
Response
post/v2/ratelimit.getOverride

Authorization

Authorizationstringheaderrequired#

Unkey uses bearer tokens for authentication. Public integrations use root keys, while the dashboard proxy uses short-lived JWTs.
To authenticate, include the token in the Authorization header of each request:

Root keys have specific permissions attached to them, controlling what operations they can perform. Legacy permissions use tuple strings like api.*.create_key; resource permissions use Unkey Resource Names plus actions, like unkey:v1:ws_123:keyspaces/*#create_key.
Security best practices:

  • Keep root keys secure and never expose them in client-side code
  • Use different root keys for different environments
  • Rotate keys periodically, especially after team member departures
  • Create keys with minimal necessary permissions following least privilege principle
  • Monitor key usage with audit logs.

Body

application/json
namespacestringrequired#
The id or name of the namespace containing the override.

Length: 1–512

identifierstringrequired#

The exact identifier pattern for the override you want to retrieve. This must match exactly as it was specified when creating the override.

Important notes:

  • This is case-sensitive and must match exactly
  • Include any wildcards (*) that were part of the original pattern
  • For example, if the override was created for 'premium_', you must use 'premium_' here, not a specific ID like 'premium_user1'

This field is used to look up the specific override configuration for this pattern.

Length: 1–512

Responses

application/json
Override found and returned successfully.
metaobjectrequired#
Metadata object included in every API response. This provides context about the request and is essential for debugging, audit trails, and support inquiries. The requestId is particularly important when troubleshooting issues with the Unkey support team.
Show child attributes
requestIdstringrequired#
A unique id for this request. Always include this ID when contacting support about a specific API request. This identifier allows Unkey's support team to trace the exact request through logs and diagnostic systems to provide faster assistance.
dataobjectrequired#
Show child attributes
overrideIdstringrequired#
The unique identifier of this specific rate limit override. This ID is generated when the override is created and can be used for management operations like updating or deleting the override.

Length: 1–255

durationintegerrequired#
The duration in milliseconds for this override's rate limit window. This may differ from the default duration for the namespace, allowing custom time windows for specific entities. After this duration elapses, the rate limit counter for affected identifiers resets to zero.

Range: >= 1000

identifierstringrequired#

The identifier pattern this override applies to. This determines which entities receive the custom rate limit.

This can be:

  • An exact identifier for a specific entity
  • A pattern with wildcards for matching multiple entities

Wildcard examples:

  • 'admin_*' matches any identifier starting with 'admin_'
  • '*_test' matches any identifier ending with '_test'
  • 'premium' matches any identifier containing 'premium'

More complex patterns can combine multiple wildcards. Detailed documentation on pattern matching rules is available at https://www.unkey.com/docs/ratelimiting/overrides#wildcard-rules

Length: 1–255

limitintegerrequired#

The maximum number of requests allowed for entities matching this override. This replaces the default limit for the namespace when applied.

Common use cases:

  • Higher limits for premium customers
  • Reduced limits for abusive or suspicious entities
  • Zero limit to completely block specific patterns
  • Custom tier-based limits for different customer segments

Range: >= 0