Rate-limiting
To ensure the stability, security, and performance of our infrastructure, we apply a rate limiting policy to API calls.
Rate limiting goals
Rate limiting is designed to:
- Protect against attacks that could exploit your API access.
- Prevent abuse or uncontrolled excessive requests.
- Ensure fair resource distribution across all partners.
- Protect our system from faulty code or aggressive automated behaviors.
- Maintain high availability of our service.
How it works
Each API call is counted, and a cap is applied over a sliding time window. If the limit is exceeded, additional requests are rejected with the appropriate error code (429 Too Many Requests).
Several limiting mechanisms are applied:
- A spike arrest to limit requests per second.
- Rate limiting to limit requests per minute.
- A daily quota to limit the total number of requests per day.
- Specific limits on some endpoints (for example,
GET /:items/:idendpoints have dedicated limits).
These thresholds may vary depending on your partnership type, environment (sandbox vs production), or a specific use case approved by our team.
Response when limits are exceeded
When a limit is reached, the API responds with:
- HTTP 429:
Too Many Requests - the following headers
| header | description | example |
|---|---|---|
| X-Quota-Limit | Total number of requests allowed during the period (e.g., 1000/day) | 100000000 |
| X-Quota-Remaining | Number of requests remaining in the quota | 99667461 |
| X-Quota-Reset | Quota reset timestamp | 1772540857844 |
| X-Rate-Limit-Limit | Maximum number of requests allowed during the period | 2750 |
| X-Rate-Limit-Remaining | Number of requests remaining in the current period | 2503 |
| X-Rate-Limit-Reset | Counter reset timestamp (epoch) | 1772524301105 |
| X-Spike-Arrest-Limit | Maximum number of requests allowed during the period | 30 |
| X-Spike-Arrest-Reset | Counter reset timestamp (epoch) | 1772524285295 |
| X-Spike-Arrest-Slice-Period | Sliding time window used to evaluate spike arrest | 100ms |
Recommended best practices
- Cache responses as much as possible to reduce redundant calls.
This is especially relevant for endpoints related to non-changing entities, such as reference data, club/network node information, etc.
- Use webhooks to be notified of creations/updates instead of synchronizing data on a fixed schedule.
- Adopt an exponential backoff strategy when you receive a
429. - Do not trigger automatic retry loops without rate control.
Do you have a BI / Data Lake / Big Data project?
APIs are not the best fit for this use case.
Resamania provides dedicated export capabilities that can fully meet your needs. Contact us via the contact form for more information.
WARNING
Do not start a BI project using our APIs, as you may hit limits (either when moving to production or due to our rate-limiting policy).
Need more capacity?
If you have legitimate use cases requiring higher volumes (e.g., large-scale synchronizations, scheduled batch calls, etc.), contact us to discuss a custom limit adjustment.
For any questions about rate limiting or to request a quota increase, you can contact our team by email.