I’ve been a PlayHT enterprise customer for approximately 18 months, managing a multi-seat license for a team that integrates the TTS API into a customer-facing application. Our usage has been consistent and well within our purchased tier's documented limits (500,000 characters per month, with a documented API rate limit of 200 requests per minute). However, for the past 72 hours, our systems have begun receiving persistent HTTP 429 "Too Many Requests" errors during periods of what we have verified to be *sub-threshold* activity.
I have conducted a thorough preliminary investigation to rule out common internal causes, which I will detail below. My primary question for the community is whether others have experienced a similar, sudden shift in API behavior from PlayHT, particularly regarding the apparent tightening of rate limiting thresholds without a corresponding update to the official documentation or prior notification.
**Our investigation thus far:**
* **Baseline Metrics:** Our average usage sits at ~65% of our monthly character quota. The 429 errors are occurring even when our real-time dashboard shows a request rate of 40-50 RPM, well under the 200 RPM limit.
* **Traffic Pattern Analysis:** We have not changed our application's burst pattern. We typically send batched requests of 5-10 individual TTS jobs every few minutes. This pattern has been stable for over a year.
* **Infrastructure Check:** We confirmed our requests are originating from a consistent set of whitelisted IPs associated with our cloud provider. There has been no expansion of endpoints or accidental deployment of duplicate client instances.
* **Error Correlation:** The 429 responses do not include a standardized `Retry-After` header. The response body is a generic JSON error. Crucially, the errors are intermittent but cluster in specific 10-15 minute windows, suggesting a possible internal quota enforcement cycle on PlayHT's side that is more aggressive than the per-minute rate limit.
**My hypotheses, which I would like to validate or refute based on others' experiences:**
1. PlayHT may have implemented a **concurrent request limit** (e.g., no more than X simultaneous connections per account) that is not published alongside the RPM limit.
2. There may be an **undisclosed aggregate character-per-hour or per-minute quota** that is now being enforced more strictly, even if the monthly total is respected.
3. This could be a regional or endpoint-specific issue. We are using the `api.play.ht` primary endpoint; has anyone using a different endpoint observed similar behavior?
I am seeking concrete data points from other teams, particularly those on enterprise or high-volume plans. Have you:
* Recently received 429 errors while operating under your documented limits?
* Successfully resolved such an issue with PlayHT support, and if so, what was the root cause communicated to you?
* Discovered any workarounds, such as implementing stricter client-side pacing or switching API endpoints?
I plan to escalate this through our vendor management channel, but community data will be invaluable in those discussions to distinguish between an account-specific anomaly and a broader platform policy change. Any shared logs or metrics (sanitized, of course) would be particularly helpful for comparative analysis.
Check the SLA.
Oof, that's a frustrating spot to be in after 18 months of smooth sailing. Your investigation looks solid, especially checking real RPM against the documented limit.
I've seen this before with other APIs, where the *effective* rate limit gets more complex than a simple requests-per-minute. A few things you might want to add to your checklist:
* Check if there's a concurrent connection limit or a limit per IP that's being shared across your team's seats, which could be the new culprit.
* Look for any recent changes in your request patterns, like a sudden burst of requests in a 10-second window that might trigger a short-term sliding window limit you weren't hitting before.
Could you share a screenshot of your request timing distribution (maybe a histogram from your dashboard)? Sometimes the spike pattern tells the real story.
Dashboards or it didn't happen.