Mastering rate limiting is essential to ensure the stability of our APIs, their optimal performance, and fair usage for everyone. In this context, a dedicated proxy layer plays a central role by precisely orchestrating traffic regulation. This article explains how the system works, how the queuing logic behaves, how 429 errors are generated, and which best practices to follow to avoid being blocked.

Subscription plans and limits

Every access to our APIs is subject to a per‑minute rate limit, depending on the chosen plan:

• Free plan: 10 requests per minute.
• Pro plan: 300 requests per minute or 5 requests per second.
• Ultra plan: 450 requests per minute or 7 requests per second.
• Mega plan: 900 requests per minute or 15 requests per second.
• Custom plan: 1200 requests per minute or 20 requests per second, for custom plans up to 1.5 million requests per day.

If you need a higher volume, you can contact us via the dashboard chat so we can discuss a suitable configuration.

Rate limit headers

When you use the API, the following headers are added to each response:

• x-ratelimit-requests-limit: number of requests allocated per day according to your subscription.
• x-ratelimit-requests-remaining: number of remaining requests for the current day.
• X-RateLimit-Limit: maximum number of allowed calls per minute.
• X-RateLimit-Remaining: number of remaining calls before reaching the per‑minute limit.

These headers allow you to adapt your client‑side logic and better spread your calls over time.

Per user and per IP limits

It is important to note that rate limiting is applied per user and per API, according to the limits defined by your subscription. In addition, the protection also takes into account the IP address used to make the calls.

In practice, this means that rate‑limit behavior depends both on your API key and on your source IP. If several users or services share the same public IP, their requests can be counted together from the network protection point of view, which may reduce your effective capacity more quickly.

For this reason, it is not recommended to call the API from environments where outbound IPs are shared among many different users. This can be the case for some managed or serverless services such as Cloudflare Workers, AWS Lambda, Google Cloud Run, Google Cloud Functions, Firebase Functions, Vercel Functions, Netlify Functions, as well as other comparable serverless or PaaS platforms.

Whenever possible, it is better to use a dedicated static IP so you keep full control over your traffic and avoid having another user on the same IP trigger protections that also affect your calls.

Orchestration with a dedicated proxy

A dedicated proxy layer orchestrates the rate‑limiting process by turning subscription limits into a simpler processing rate. For example, if a user is on the Mega plan with a limit of 900 requests per minute, this layer converts it into an operational rate equivalent to 15 requests per second.

As long as the user stays below this threshold, rate limiting remains inactive and interactions with the API behave normally, without any particular constraint.

In the image below, the 15 requests received within the same second are processed immediately, because they stay within the limit allowed by the user’s plan:

Moderate exceeding: queuing requests

With the same example of a Mega plan allowing 15 requests per second, if a user sends 18 requests, the proxy immediately processes the first 15 and puts the remaining 3 on hold, to process them sequentially as soon as a new slot becomes available.

In other words, these extra requests are temporarily paused and then executed as soon as the traffic goes back under the threshold of 15 requests per second.

This queuing mechanism, called burst, makes it possible to briefly absorb a small overload without immediately rejecting calls.

The image below illustrates this case: the first requests are accepted immediately, while the following ones are delayed and then processed as soon as a slot becomes available:

Exceeding the limit and 429 errors

If a user exceeds the allowed rate to a point where the burst mechanism can no longer absorb it, rate limiting fully kicks in.

In the example below, 23 requests are sent: the first 15 are processed immediately, the next 5 are queued to be executed as soon as a slot is free, but the last 3 are rejected.

The next image shows exactly this situation, with three visible categories:

For rejected requests, the API returns an HTTP 429 Too Many Requests error.

Example of a 429 response:

{
    "get": "",
    "parameters": [],
    "errors": {
        "rateLimit": "Too many requests. You have exceeded the limit of requests per minute of your subscription."
    },
    "results": 0,
    "paging": {
        "current": 1,
        "total": 1
    },
    "response": []
}

Receiving 429 responses means your client is sending too many requests in too short a time window. In this case, you must slow down, spread your calls out, and implement a retry mechanism with progressive backoff.

Rate limiting policy and firewall

If you exceed the number of requests allowed per minute, either through continuous over‑consumption or by generating abnormal traffic spikes, your access may be temporarily or permanently blocked by the firewall, without prior notice.

This block can target the API key used, but also the IP address from which the calls originate. The goal is to protect the stability of the service and ensure fair usage for all customers.

In other words, sending a very large number of requests at once, or continuing to call the API beyond your plan limits, does not only result in 429 errors: it can also trigger a temporary block on the IP or the API key used.

To avoid this, it is recommended to:

• Smooth your calls over time instead of sending large bursts.
• Use server‑side caching whenever possible.
• Avoid unnecessary duplicate requests.
• Take the rate‑limit headers into account.
• Slow down immediately when a 429 error appears.

Conclusion

Rate‑limit management with a dedicated proxy layer is a delicate balance between ease of use, infrastructure protection, and fairness between users. The system can absorb small spikes thanks to burst, while rejecting or blocking usage that exceeds plan thresholds over time.

It is also important to remember that rate‑limit behavior depends not only on your subscription and your API key, but also on the IP used to make calls. For production integrations, using a dedicated static IP remains the best way to avoid side effects caused by shared IPs.

Finally, if none of our standard plans or their associated limits match your needs, you can contact us directly via the dashboard chat to set up a custom service. For the full policy and up‑to‑date information, please refer to the official documentation.

The API-SPORTS Team