When your site makes frequent requests to a third-party API and starts hitting rate limits or timing out, the fix usually involves being more efficient about when and how often those requests happen — caching responses, batching requests, backing off appropriately — since the limit itself is set by the third-party service and isn’t something we can simply raise.
Check the API’s own documentation for its specific rate limit
Most APIs publish their rate limits directly in their documentation (requests per minute or per day). Comparing your site’s actual request volume against that published limit tells us whether you’re genuinely exceeding it, or whether something else is causing the errors despite staying within bounds.
API rate limit & timeout handling
API calls hitting rate limits, made efficient with caching and backoff — we can't raise the limit itself.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Your site is hitting rate limits or experiencing timeouts when calling a third-party API | This fix covers it |
| The API errors are from a custom endpoint you built yourself, not a third-party API | Custom API endpoint errors, the equivalent issue for your own API |
| You want the underlying integration set up for the first time, not an existing one optimised | A different, initial setup task depending on the specific service involved |
| The third-party service itself is having a documented outage | Outside what we can fix — that’s the service’s own issue, on their timeline |
What you are seeing
- API requests failing with a rate limit error from the third-party service
- Requests timing out rather than completing within an expected timeframe
- The issue possibly worsening during periods of high site traffic
- Errors possibly starting after the API provider changed their rate limit policy
Common causes
- Requests made more frequently than necessary, without caching results that don’t need to be fetched fresh every time
- No retry or backoff logic, so a single rate limit hit cascades into repeated, immediate failed retries
- A traffic spike on your site causing a corresponding spike in API calls beyond what the service allows
- The API provider changing their rate limit policy or tier without your integration being updated to match
- Two unrelated plugins independently calling the same API with no shared awareness of each other’s usage against the same limit
What we do
- Analyse actual request patterns against the API’s published rate limits
- Implement caching for responses that don’t need to be fetched on every single request
- Add appropriate retry and backoff logic for when limits are genuinely hit
- Batch requests where the API supports it, reducing overall call volume
- Test under realistic load to confirm improved behaviour
- Monitor initial results to confirm rate limit errors are reduced or eliminated
What is included
- Request patterns optimised to reduce unnecessary API calls
- Caching implemented where appropriate
- Retry and backoff logic added for genuine rate limit situations
- Monitoring to confirm improved behaviour following the fix
Not included
- Increasing your actual rate limit allowance — that requires a different plan or arrangement with the API provider, not something a technical fix here can grant
- Rebuilding the entire integration if the current approach is fundamentally, extensively flawed — worth discussing scope if that’s what’s found
- Resolving a genuine outage or policy issue on the API provider’s own side
- Ongoing monitoring as your site’s traffic or usage patterns change significantly
Questions about this fix
Can you just get my rate limit increased?
Not directly — the limit is set by the third-party API provider, typically tied to your account tier or a specific request or negotiation with them; we can make your site use its allowance more efficiently, but we can't grant you a higher limit ourselves.
Why would caching help with a rate limit problem?
If the same data is being requested repeatedly when it doesn't actually change that often, caching it means you're not making a fresh API call every single time, which directly reduces how many requests count against your limit.
What does 'backoff logic' actually mean?
It means that when a rate limit is hit, the system waits an increasing amount of time before retrying, rather than immediately hammering the API again and again, which would otherwise make the situation worse rather than better.
Could increased site traffic really cause this on its own?
Yes — if API calls scale directly with visitor traffic, a genuine increase in visitors can push you past a rate limit that was previously comfortable, even without anything else about the integration changing.
Will this completely eliminate rate limit errors going forward?
It significantly reduces the likelihood by making usage more efficient, though a limit is still a limit — a large enough spike in genuine demand could still hit it, which is a structural characteristic of the constraint rather than something eliminable entirely.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.