The API now exposes more safety limits at the edge

Speechify added a set of edge-safety changes to make API failures easier to predict. Rate limits are more visible, oversized JSON bodies now fail with 413, unsupported request content fails with 415, and token-mint paths have pre-auth IP throttling.

None of this is flashy. It is the work that keeps production integrations from failing in vague ways.

Rate-budget headers

Rate-limited routes now expose budget headers for the two axes that matter: request rate and concurrency or active-call capacity. If your client is close to a ceiling, you can see it in the response instead of waiting for a 429 and guessing which bucket fired.

Use that signal for backoff, dashboards, and customer-facing diagnostics. It is much better than hardcoding sleeps.

Body-size and content-type errors

Large JSON bodies now share one decode path. A body that is too large returns 413. A request with an unsupported media type returns 415. Both use the standard Speechify error envelope with request_id, so the support path is still one shape.

Uploads have route-specific overrides where the API expects large multipart bodies. We fixed that interaction immediately after the first global cap landed because voice-clone samples and knowledge-base documents are not JSON payloads.

Pre-auth throttling

Token-mint endpoints now have an IP-level limiter before auth runs. That protects the credential-exchange path from unauthenticated bursts, but it has enough headroom for normal enterprise NAT setups and a config lever for unusually large networks.

This is the kind of limit most callers should never notice. If they do, the response should now be clear enough to debug without spelunking logs.