Limits are part of the product
Limits are set by access level and by plan. A limited response shows the current values, and a caller who goes over the limit receives a 429 response with Retry-After.
← All capabilities
Available now
Platform capability · Rate Limits & Quotas
The same rate limits and plan limits on every service
One shared way to enforce limits on protected endpoints
Platform services share one rate-limit component. Limits are set for each access level and are counted centrally, so they apply across all copies of a service. A limited response carries standard limit headers, and a 429 response includes Retry-After. Product limits can be declared as whole-number plan features and enforced through the SDK, and metered usage is reported to the platform.
Built in
What you get
- One shared rate-limit component used by every service
- Limits are counted centrally, so they apply across all copies of a service
- 429 responses with Retry-After
- Limits set for each access level: public, operator, customer and internal
- X-RateLimit-Limit, Remaining and Reset headers on limited responses
- Plan limits from the app declaration, enforced through the SDK
- Metered usage reported through the SDK and added up by the platform
Under the hood
How it works
Headers show how much of the limit is left
Every limited response includes X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. A 429 response includes Retry-After. Clients can slow down by themselves without guessing, which reduces questions about why requests were refused.
Further additions
Additions that extend the capability described above.
- Detection of abuse patterns (repeated sign-in attempts, scraping)
Want a deeper walkthrough of Rate Limits & Quotas?
A solution architect will demo the live service against your domain model.