Speechify Release Notes

API: default MP3 output is now 128 kbps

Requests that ask for MP3 without naming a bitrate now receive 128 kbps instead of 64 kbps. That is audio_format: "mp3" on POST /v1/audio/speech and POST /v1/audio/dialogue, and Accept: audio/mpeg on POST /v1/audio/stream and POST /v1/audio/stream/with-timestamps. The sample rate, channel count, duration and container are unchanged: 24 kHz mono MP3, as before.

At 24 kHz mono, 64 kbps left compression noise only about 12-14 dB below the signal across the 2-11 kHz band, which is audible on sibilants and on the quiet tail of a phrase. 128 kbps puts that noise about 30 dB down, which is where the quality curve stops paying for itself - 160 kbps measures roughly 1 dB better again for 25% more bytes.

What this means for your integration:

• Responses are about twice as large for the same text. Time-to-first-byte is unchanged: the encoder emits its first frame after a fixed amount of audio regardless of bitrate.
• Nothing in the response shape changes. audio_format still reads mp3, and output_format is still echoed only when you set it.
• On /v1/audio/speech and the two stream routes, keep the previous output by sending output_format: "mp3_24000_64". Any request that already names an output_format is unaffected - this changes only what an unspecified bitrate resolves to.
• POST /v1/audio/dialogue has no output_format field, so it has no per-request bitrate control and never did: audio_format: "mp3" there simply encodes at 128 kbps now instead of 64. Use wav or pcm if you need the unencoded audio.

The set of output_format values you can ask for is unchanged. As the audio_format field has always documented, the resolved default is not part of the contract: name the output_format you want if your pipeline depends on it.

Original source

Consent verification now checks who is speaking, not only what they said. A create whose consent_recording reads the phrase correctly but in a different voice from your sample is refused with 422 consent_speaker_mismatch and no voice is created.

This closes the gap the flow was always meant to close: the person consenting has to be the person being cloned, so permission relayed by somebody else - an account holder reading the phrase on a speaker’s behalf - does not pass.

consent_speaker_mismatch is not a new code, and clients that already branch on it need no change. What is new is that it fires. If you tested your integration by reading the phrase yourself against someone else’s sample, that path now returns a 422; put the challenge in front of the speaker instead. Re-reading the same phrase does not help, which is why this is a distinct code from consent_phrase_mismatch. See Consent.

Original source

Creating a cloned voice now requires proof that the speaker agreed to it, in place of the consent object you used to send.

The flow adds one call in front of your existing create. POST /v1/voices/consent-challenges with the speaker’s full_name returns a phrase and an id. Show the phrase to the speaker exactly as it comes back, record them reading it aloud, and send that recording as consent_recording with consent_challenge_id on POST /v1/voices. Speechify transcribes the recording, checks it against the phrase it issued, and keeps it as the consent record for that voice.

A challenge is single use, bound to your workspace, and short-lived, so create it when your speaker is ready to record rather than at the start of your flow. If it expires, create another one and record again.

The unverified flow is deprecated and will be switched off. The date will be announced in this changelog and to affected workspaces ahead of time; plan for a window deliberately shorter than the standard 12-month sunset, because an endpoint that clones a voice without checking the speaker agreed is a safety liability, not just an old shape. The new shape is Speechify-Version: 2026-09-13; it is callable now by pinning that version, and it becomes the default for new workspaces on that date. Until the switch-off, workspaces pinned to earlier versions keep the old consent object, and a pinned default does not move on its own: migrating means re-pinning 2026-09-13. Existing cloned voices are unaffected and keep working, and synthesis endpoints are unchanged.

If you cannot migrate ahead of the switch-off, contact support and we will work out an extension for your workspace.

One thing to know if you use an SDK: each release sends its own build date as the default version, so upgrading to an SDK published on or after 2026-09-13 moves you to the new flow even though your workspace is pinned to the old one. That is a deliberate break rather than a silent one - consent_challenge_id and consent_recording are required arguments on the new create, and the consent argument is gone, so the call stops building rather than failing at runtime. To upgrade the SDK without migrating yet, pass the version explicitly:

client = Speechify(token=os.environ["SPEECHIFY_API_KEY"], version="2026-08-07")

Migrating: full_name moves from the consent object onto the challenge call, email is dropped and nothing replaces it, and consent_challenge_id plus consent_recording become required.

Three of the new error codes share HTTP 422 and mean different things, so branch on the code rather than the status: consent_phrase_mismatch (the phrase was misread - read it again), consent_speaker_mismatch (the person in the recording is not the person in the sample - the speaker consenting has to be the speaker being cloned), and consent_recording_unusable (silence, too little speech, or an unreadable file - record it again). See Consent and the Voice Cloning API.

Original source

Content Policy

Text you send for synthesis is now screened before Speechify produces audio from it. A request whose content is not permitted returns 400 content_policy_violation with no audio, and is not billed. This applies to /v1/audio/speech, /v1/audio/stream, /v1/audio/stream/with-timestamps and /v1/audio/dialogue, and to an agent’s prompt and first_message when you create or update one.

Most published work is unaffected - fiction, journalism, true crime and court reporting routinely describe or quote violence, and depicting that material is treated differently from producing it.

One thing worth handling in your client: content_policy_violation is a persistent error, so retrying the same text will be refused again. On the streaming endpoints the decision is always made before the first audio byte, so a 200 means the request passed and a refusal is always a JSON 400, never a truncated or empty audio file. See Content Policy.

Original source

API: simba-3.2 voice cloning enters limited release

Cloned (personal) voices now synthesize on simba-3.2 for workspaces enabled for it, with no per-voice step. The earlier per-voice-key approval is gone: enablement is per workspace, and once yours is on, every clone you own works there. Contact us to be enabled.

Nothing else changes. The request and response are identical to a stock-voice call, and simba-3.2 remains English only, so a cloned voice with a non-English locale still returns 400 — use simba-3.0 for those.

GET /v1/voices names simba-3.2 on your cloned voices once your workspace is enabled, so drive a picker off each voice’s models array rather than assuming. Cloning on simba-3.0, simba-english, and simba-multilingual is unchanged.

Original source

API: simba-3.0 is the new default TTS model

POST /v1/audio/speech, POST /v1/audio/stream, and POST /v1/audio/stream/with-timestamps now resolve a request that omits model to simba-3.0 instead of the legacy simba-english.
GET /v1/audio/models marks the change on its default flag.

Nothing you already send changes shape, and nothing that worked starts failing. A request that names a model explicitly is untouched - model: "simba-english" keeps getting Simba 1.6 English, and that model stays fully supported with nothing scheduled for removal.

What changes if you omit model:

Before (simba-english) Now (simba-3.0) Voices accepted any voice in GET /v1/voices unchanged - any voice, cloned voices self-serve Non-English voices synthesized by the English 1.6 training routed to the Simba 3.0 multilingual training POST /v1/audio/stream/with-timestamps 400 speech_marks_unsupported supported Audio Simba 1.6 Simba 3.0 - streaming-native, lower time-to-first-byte

simba-3.0 was chosen over the recommended simba-3.2 precisely because it accepts everything the old default did: simba-3.2 serves a curated voice set and rejects non-English voices, so making it the default would have turned working calls into 400s.

The rendered audio does change if you omit model.
Pin the old behaviour by sending model: "simba-english" explicitly if your integration depends on the Simba 1.6 output. For new English work we still recommend model: "simba-3.2" - see Models.

Original source

Models list now reports per-model endpoints and curated-voice flag

GET /v1/audio/models now returns two new fields for each model:

• endpoints — the synthesis routes this model may be passed to. Passing a model to an endpoint its endpoints list omits returns 400.
• curated_voices — when true, only voices that explicitly name this model in their models array are accepted. When false, every catalogue voice works, including workspace clones.

Both fields are surfaced to help a model picker show only valid combinations and reject unsuitable voice selections before the request reaches the server.

Original source

API: Free tier gets a burst allowance on /v1/audio/*

The Free plan’s TTS rate limit no longer caps its burst bucket at the sustained rate. Previously Free was 1 request/second with a bucket capacity of 1, so a second request issued in the same second was rejected with 429. Free now gets a burst capacity of 10, so a normal opening burst of requests (a quickstart script, a first integration test) no longer trips the limiter.

Plan Sustained requests/second Burst
Free 1 10
Starter 20 60
Pro 40 120
Scale 80 240
Enterprise 150 450

Sustained throughput is unchanged on every tier — burst only smooths the first second of traffic; it does not raise your steady-state rate. This brings /v1/audio/* in line with the burst allowance /v1/agents/* has had since rate and concurrency limits were first published.

See the API limits reference for the full per-plan table.

Original source

API: canonical Speechify-* header names (legacy X- aliases still work)

Every header in Speechify’s public API surface now has one canonical, un-prefixed Speechify-* name (RFC 6648). The pre-2026 X- -prefixed spellings are unaffected today - they’re still accepted on requests and still emitted on responses - and will keep working until 2027-07-24.

Legacy (still works until 2027-07-24) Canonical X-Request-ID Speechify-Request-Id X-Speechify-Audio-Content-Type Speechify-Audio-Content-Type X-RateLimit-Limit / -Remaining / -Reset RateLimit-Limit / -Remaining / -Reset X-Speechify-SDK / X-Speechify-SDK-Version Speechify-SDK / Speechify-SDK-Version X-Tenant-ID Speechify-Tenant-Id

The last two are request headers - if your integration sends them, either spelling is read the same way. X-Speechify-Billable-Characters-Count (an internal usage-accounting header on the audio-streaming responses) is unaffected by this change and has no canonical form.

Nothing to change today: whenever a response carries one of these headers, it carries both spellings with the same value, so an integration reading either name keeps working unmodified. Speechify-Audio-Content-Type is only present on the audio-streaming endpoints that already emitted its X- predecessor - it doesn’t appear on responses that never had it, like POST /v1/audio/speech. New integrations should read the canonical name.

Speechify-Request-Id: 7f3a2c1b4d5e6f7a
X-Request-ID: 7f3a2c1b4d5e6f7a
RateLimit-Limit: 20
X-RateLimit-Limit: 20

(RateLimit-Limit reflects your plan’s request-rate budget - the value above is illustrative, not a specific plan’s limit. See the API limits reference for the per-plan table.)

If you send a request-correlation id yourself, send it as Speechify-Request-Id (the legacy X-Request-ID request header is still echoed back the same way). If both are sent, the canonical name wins.

Full header reference: API limits & rate limiting.

Original source

API: stream speech marks with POST /v1/audio/stream/with-timestamps

A new endpoint streams word-level speech marks alongside audio, so text highlighting, captions, and audio-text sync no longer need the batch POST /v1/audio/speech round trip.
POST /v1/audio/stream is unchanged - same request body, still plain audio.

The response is a Server-Sent Events stream:

• speech.chunk carries a Base64-encoded run of audio, the speech marks that became final with it, or both - either field may be absent, and the last chunk of a stream is often marks-only.
• speech.done is terminal; there is no [DONE] sentinel.
• speech.error carries the standard error envelope when a failure happens after the stream has started (the status code is already committed by then).
• Ignore any event type you do not recognize, so new event types never break your integration.

Speech-mark times are absolute milliseconds from the start of the synthesis - concatenate the audio chunks into one stream and apply the marks against that single timeline. Which chunk a mark arrives on is a delivery detail with no meaning of its own, and times stay correct across every output_format.

Marks are produced by the streaming-native models: use simba-3.0 or simba-3.2.
simba-english and simba-multilingual return 400 speech_marks_unsupported on this endpoint - use POST /v1/audio/speech for a non-streamed response with marks on any model.

Original source

API: simba-3.0 now synthesizes six European languages

simba-3.0 is no longer English-only. It now officially supports English plus German, Spanish (Spain and Mexico), French, Italian and Brazilian Portuguese:

Language | Code
English | en-*
German | de-DE
Spanish (Spain) | es-ES
Spanish (Mexico) | es-MX
French | fr-FR
Italian | it-IT
Portuguese (Brazil) | pt-BR

Nothing changes in your request shape. Keep passing model: "simba-3.0" and set the language parameter to the language of your input; when you omit language, the voice’s own locale decides. English and non-English are served by two separate trainings behind the scenes, but that routing is internal, so the model ID you pass never changes.

Example curl request:

$ curl -X POST https://api.speechify.ai/v1/audio/speech \
> -H "Authorization: Bearer $SPEECHIFY_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{
> "input": "Bonjour, comment allez-vous ?",
> "voice_id": "oliver",
> "model": "simba-3.0",
> "language": "fr-FR"
> }'

A non-English voice on simba-3.0 previously returned 400; those requests now synthesize. Languages outside the supported set often produce usable audio but are not validated - use simba-multilingual for the full 30+ locale set. simba-3.2 remains English-only and stays the recommendation for English integrations.

GET /v1/audio/models reports the new coverage in simba-3.0’s languages array, so a picker driven by that endpoint picks it up with no code change.

Simba 1.6 models marked legacy

GET /v1/audio/models carries a new deprecated boolean, set on simba-english and simba-multilingual:

{
  "id": "simba-english",
  "name": "Simba English",
  "default": true,
  "recommended": false,
  "deprecated": true,
  "description": "Legacy Simba 1.6 English model, still the default when a request omits `model`. Prefer simba-3.2.",
  "languages": ["en"]
}

The flag is advisory. Both models stay fully supported and behave exactly as before, and nothing is scheduled for removal - simba-english is still the model a request resolves to when it omits model, so it cannot be withdrawn. Treat deprecated as a signal to de-emphasise a model in a picker and steer new integrations elsewhere: simba-3.2 for English, simba-3.0 for the languages it covers.

simba-3.0 accepts cloned voices

The docs previously said Simba 3.0 served a curated voice set and rejected cloned/personal voices. That was not what the API did: simba-3.0 accepts the full built-in catalog and any cloned voice, self-serve. The documentation now matches the behavior.

simba-3.2 is unchanged and remains the one model with a curated voice set, plus cloned voices Speechify has manually approved.

Playground language picker

The Console TTS playground now has a language selector next to the model picker. Choosing a multilingual model lets you set the language parameter directly, and the sample text follows your choice so you have something in that language to synthesize.

Original source

API: filter GET /v1/voices by type, locale, gender, and model

GET /v1/voices now accepts four optional query filters:

Filter Values Description type personal, shared personal (the workspace’s cloned voices) or shared (the public catalogue). Omit to return both. locale BCP-47 range Prefix-matched and case-insensitive: en matches en-US and en-GB; en-US matches only en-US. gender male, female, not_specified Omit to return all genders. model a model id, e.g. simba-3.2 Voices that advertise the model in their models[]. Omit to return voices for all models.

For example, fetch the catalogue voices that speak English and support simba-3.2 :

$ curl "https://api.speechify.ai/v1/voices?type=shared&locale=en&model=simba-3.2" \
> -H "Authorization: Bearer $SPEECHIFY_API_KEY"

Filters compose with pagination: pass limit (max page size 200) and page with cursor, reading until has_more is false.

Original source

The API limits reference now lists the per-plan rate limits (sustained requests per second, plus a burst allowance on Agents) and concurrency limits (simultaneous in-flight requests) for every plan, across both the audio (TTS) and Agents surfaces. Limits apply per account, not per API key.

429 Too Many Requests responses are now self-describing:

• A Retry-After header tells you when to retry.
• The error code distinguishes the two cases: rate_limited (too many requests per second) versus concurrency_limited (too many simultaneous requests).
• The error envelope carries a docs_url that links straight to the limits reference, which lists your plan’s limits and how to raise them.

Rate and concurrency limits rise with your plan, and Enterprise limits are starting points rather than hard caps.

Original source

API: simba-3.0 now supports cloned/personal voices

simba-3.0 now accepts cloned and personal voices on POST /v1/audio/speech and POST /v1/audio/stream. Pass a cloned voice’s voice_id with model: "simba-3.0", the same way you would with simba-english. Zero-shot clones (from a 10-30 second sample) are supported self-serve; fine-tuned voices remain on simba-english and simba-multilingual (contact sales).

Example JSON:

{
  "input": "This is my cloned voice speaking.",
  "voice_id": "voice_demo0001",
  "model": "simba-3.0"
}

simba-3.2 also supports voice cloning, but each cloned voice currently requires manual Speechify approval of the voice key before use. For self-serve cloned-voice synthesis without approval, use simba-3.0, simba-english, or simba-multilingual.

Original source

Cloned (personal) voices can now be synthesized on simba-3.2. Given the model’s quality bar, each cloned voice must first be reviewed and approved by Speechify — contact us to have a voice key approved for simba-3.2 — while we evaluate stronger safeguards. This is zero-shot cloning, gated only on that manual approval step.

simba-english and simba-multilingual continue to serve cloned voices self-serve, with no approval step and no change to existing integrations; simba-multilingual still speaks one cloned voice across 30+ languages. Once Speechify has approved a cloned voice key, pass it as voice_id with model: "simba-3.2".

Original source