Hi everyone — hoping to tap into the collective wisdom here. We've been using WellSaid Labs' API in a production workflow for several months without issue, but as of yesterday we're suddenly and consistently hitting 429 "Too Many Requests" errors under what I'd consider our normal, predictable load.
Our usage pattern hasn't changed: we batch process text-to-speech for customer support snippets, typically peaking at around 300-350 requests in a 10-minute window during business hours. We've always stayed well within the documented rate limits as we understood them, and we implement a basic exponential backoff for retries. The errors began abruptly, and even after scaling back our request rate significantly, the 429s persist almost immediately. Our account dashboard doesn't show any alerts or changes to our plan limits.
I'm trying to diagnose whether this is a potential shift in WellSaid's internal rate-limiting policy, an issue with how they're calculating our usage window, or something on our end we might be misinterpreting. Has anyone else experienced a sudden change like this recently?
If you've navigated similar issues with their API, I'd be particularly interested in:
- Whether you found their rate limits are actually applied on a per-second or per-minute basis, and if the counting might include retry attempts.
- If contacting their support yielded any clarification on "burst" limits or concurrent request caps that aren't explicitly detailed in the main documentation.
- Any insight into whether API limits are tied to the specific voice model used, as we do switch between a few different avatars.
We're currently in a bit of a bind with our workflow stalled, so any shared experiences or troubleshooting steps would be immensely appreciated. I'll also update this thread with any findings from our side or from support.
— Grace
Stay curious.
That's a frustrating situation for sure, especially when nothing on your end changed and you've already throttled back. One thing that might be worth double-checking is the actual HTTP response headers you're getting back alongside those 429s. Some APIs include a Retry-After header that gives you a precise wait time, and others might include X-RateLimit-Remaining or X-RateLimit-Reset fields that could hint at whether WellSaid is using a sliding window vs a fixed calendar window for counting requests. If those headers have suddenly started appearing with very low or zero remaining counts even after you've backed off, that would strongly point to a server-side policy shift rather than a client bug.
Also, if you haven't already, I'd recommend reaching out to their support with a few specific timestamps and the exact request IDs (if they provide them) from your logs. Sometimes internal teams can tweak rate limit quotas or burst configurations without updating the public docs or dashboard - it's not great practice, but it happens. Mention that your account dashboard shows no change, because that inconsistency is something they should be able to explain.
Have you compared the response headers you're seeing now with archived ones from a few weeks ago? Even a minor difference in the header names or values could be a clue.
Stay curious.
Did you check your billing? A sudden 429 with no dashboard change could be a quota issue if your payment method expired or a usage cap you didn't know about was triggered. It's happened to me with other services.
Also, verify the exact rate limit definition in their docs. Sometimes "per 10 minutes" is actually a rolling window, not a fixed clock window. A batch at 9:55 and another at 10:05 might be overlapping in their count if it's rolling.
300 requests in 10 minutes is 0.5 requests per second average. That seems fine, but if they've changed to measuring concurrent connections or requests per second peak, you could be hitting a new, lower threshold.
Ask me about hidden egress costs.