Rate Limiting & Quotas cap how much any caller can consume your APIs — protecting your backing resources from bursts and enforcing per-client entitlements over longer periods.
Overview
Both rate limits and usage quotas are applied as policies attached to an access profile, an endpoint, or a collection. They are enforced before the backing resource is invoked, so throttled callers never reach your automations. Configure them early — a limit you add after traffic starts is harder to tune than one set from the beginning.
How Rate Limits Work
A rate-limit policy uses a fixed-window algorithm. Configure three things:
Number of requests — how many calls are allowed in the window.
Duration — the length of the window as a number.
Unit — seconds, minutes, hours, or days.
For example, "100 requests per 1 minute". The platform counts requests within each fixed window; once the count is used up, further requests are rejected with 429 Too Many Requests until the window rolls over and the count resets. Set a custom message in the policy to tell callers what happened — for example, "Rate limit exceeded. Maximum 100 requests per minute."
What the Caller Sees
A throttled request receives 429 Too Many Requests with the message you configured on the policy in the response body. The backing resource is never invoked — the limit is enforced entirely at the gateway. Once the current window passes, the allowance resets and calls succeed again. Well-behaved clients should treat a 429 as a signal to back off and retry after the window expires.
Rate Limit Scope
A rate limit is tracked per access profile, per policy — each client's access profile gets its own independent counter, so one busy client cannot exhaust another client's allowance. Where the policy is attached controls what it covers:
Access profile — limits that client across everything it can call.
Endpoint — limits all callers on that specific endpoint, regardless of which profile they use.
Collection — limits all callers across all endpoints in the collection.
The limit is enforced consistently across all servers (coordinated centrally), so the cap holds regardless of which server handles the request.
Rate Limit vs Usage Quota
Rate Limit | Usage Quota | |
|---|---|---|
Window | Short — seconds to hours | Long — daily or monthly |
Purpose | Protect against traffic bursts; keep responses smooth | Enforce total consumption caps; tied to a plan or agreement |
Resets | Every window (for example, every minute) | At the end of the quota period (for example, midnight each day) |
Typical trigger | A runaway script or unexpected traffic spike | A partner reaching their contracted monthly allowance |
You can apply both to the same client — a rate limit to prevent bursts and a quota to enforce the longer-term entitlement.
Setting a Sensible Limit
Base the limit on two things: what your backing resource can comfortably handle, and what each client legitimately needs. Start from the lower of the two, leave headroom for normal bursts, and set a clear message so callers know the limit and can back off gracefully. Apply a baseline limit at the collection, then create tighter per-profile policies for clients with lower entitlements or for expensive endpoints. Watch the Insights dashboard for 429 rates after deployment — frequent 429s for legitimate callers usually means the limit is too tight; a flat, low error rate means it is working quietly.
Notes
Always set a custom message on rate-limit policies — callers need to know the limit to implement correct retry logic.
Apply a default rate limit at the collection level as a safety baseline, then tighten per profile for clients with lower entitlements.
Combine a rate limit and a usage quota on the same access profile when you need both short-term burst protection and a long-term consumption cap.
Check the Insights dashboard for 429 rates regularly, especially after a new client is onboarded, to confirm the limits are appropriate.
The fixed-window algorithm resets counters at the start of each new window — plan for legitimate clients to experience a burst of rejected calls right at window boundaries if they are at the limit.