Limits & Quotas
API rate limits
Overview
Plan API traffic against the limits documented for your service and deployment. This page does not establish a default numeric quota, burst allowance, or account entitlement.
Separate the number of API requests from the amount of execution work they create. Reducing polling does not necessarily reduce concurrent test activity, and cancelling a client request may not cancel work already accepted.
Step-by-step procedure
Identify the limiting boundary
Confirm whether a limit applies to an account, identity, endpoint, time window, or concurrent operation. Obtain the applicable values from the supported interface or account team.
Handle throttling explicitly
When the service returns a throttling response, inspect its documented retry guidance. Respect Retry-After when supplied, bound retries, and use jitter to avoid synchronized retries across workers.
Measure before expanding
Record peak request volume, retry counts, latency, and the workflow affected. Request capacity changes with that evidence and the expected growth; do not assume that a plan name guarantees a higher limit.
Key concepts
- Rate limit
- A restriction on request volume over a defined scope and interval.
- Idempotence
- Repeating an operation has the same intended effect as performing it once; confirm the endpoint contract before retrying writes.
Best practices
- Avoid unbounded polling or retry loops.
- Coordinate request budgets across workers sharing an account.
- Keep request diagnostics free of credentials and sensitive payloads.
Common issues
- Retries create more work
- A write may have been accepted even when the response was lost. Reconcile the outcome before retrying a non-idempotent operation.
Was this page helpful?