Rate Limits

To ensure system stability and fair resource distribution, these APIs utilize a multi-tiered rate-limiting strategy. Each API key is linked to a specific usage plan that defines steady-state throughput and the capacity for brief traffic spikes.

Core Concepts

Documentation often conflates rate and burst. In this ecosystem, they represent two distinct architectural constraints:

• Sustained Limit: The long-term throughput allowed for an integration. This is the number of requests permitted over a fixed time interval. For instance, if the sustained limit is one request per four seconds, sending two requests within three seconds will trigger a 429 error.
• Burst Capacity: The number of "tokens" available for immediate, simultaneous use. A burst capacity of four allows for four requests to be sent at the exact same millisecond. Once exhausted, the account must "refill" at the sustained limit rate before further requests are accepted.
• Method-Specific Limits: POST operations (write actions) are throttled more aggressively than GET operations (read actions) in certain tiers to protect database integrity and downstream processing.

Handling Throttling (HTTP 429)

When an application exceeds these limits, the API Gateway returns an HTTP 429 Too Many Requests status code. Robust integrations should implement the following recovery patterns:

1. Exponential Backoff: Avoid immediate retries. Increase the delay between each consecutive attempt.
2. Jitter: Introduce a random interval to backoff logic to prevent "thundering herd" scenarios where multiple clients retry at the same time.
3. Local Caching: For GET requests, cache responses locally to minimise redundant calls and preserve your rate limit quota.

---

Usage Plan Reference Table

Rate limits are strictly enforced based on the plan associated with your API key.

If your integration requirements exceed the limits defined above, contact your professional services representative to discuss a plan upgrade.