Speechify Release Notes

API: projects, webhook endpoints and workspace entitlements are in the API reference and SDKs

Three workspace surfaces that Build integrations already rely on are now in the API Reference and the official SDKs:

• Projects (/v1/projects): model each of your customers as a project, cap its spend with monthly_budget, pin API keys and members to it, and archive, purge or restore it.
• Webhook endpoints (/v1/webhooks/endpoints): subscribe to the workspace.spend_budget., project.spend_budget., and api_key.spend_cap.* events, rotate the signing secret, and read delivery attempts.
• Workspace entitlements (GET /v1/workspaces/current/entitlements): what your plan allows, including the TTS request-rate and concurrency limits.

Nothing changes on the wire. These endpoints already answered API-key requests; this release documents them and adds them to the SDKs.

See Spend Limits and Projects for how they fit together.

Original source

The consent form field on POST /v1/voices

The pre-verification flow that took a typed name and email as the speaker’s consent stops working on 2026-10-07 for every workspace, whatever API version it is pinned to. From that day a create needs a consent challenge: POST /v1/voices/consent-challenges, a recording of the speaker reading the phrase, and consent_challenge_id + consent_recording on the create. The migration guide walks the two calls.

Some workspaces were told in August that this flow would stop on 1 September. It did not, and nothing was switched off without notice; this entry is the date that holds.

What changes on 2026-10-07. A POST /v1/voices that still sends consent and no consent_challenge_id returns 400 with the error code consent_verification_required. The message names this date and links the guide. Requests that already send a challenge are unaffected, and so is every existing cloned voice and every synthesis call.

Read it off the wire. Until then, every create on the old flow answers with RFC 9745 Deprecation and RFC 8594 Sunset headers carrying this date, and a Link to the guide with rel="deprecation". If your integration logs response headers, the deadline is already in your logs.

Why the short window

Our default sunset is 12 months. This one is shorter, as the 13 August entry said it would be, because an endpoint that clones a voice without checking the speaker agreed is a safety liability rather than an old request shape.

Need longer? Contact support before the date with the workspace and the reason, and we will work out an extension.

Original source

API: Simba 1.6 keeps working after 2026-11-21, served by our current models

simba-english and simba-multilingual no longer stop working on 2026-11-21. On that date their Simba 1.6 training is switched off and both ids are served by our current models instead:

If you send From 2026-11-21 it is served by simba-multilingual our current multilingual model, in every language it is sent today simba-english, English text simba-3.2 simba-english, any other language our current multilingual model

This replaces the “switched off for every API version” in the 2026-09-21 entry. The retirement itself is unchanged: from API version 2026-09-21 neither id is selectable and naming one returns 400 model_retired, so a workspace pinned before that date is the only place either id still answers.

Nothing breaks, but the audio changes. A voice you tuned on Simba 1.6 is rendered by a different model, and SSML , , , and <speechify:style emotion> are not applied by the current models (breaks and are). The request, the response, the voice IDs and the price stay the same. If you want to choose the model and test your voices before the date, switch the model string yourself: Migrating off Simba 1.6 walks it step by step.

GET /v1/audio/models keeps carrying retired_at: "2026-09-21" and sunset_at: "2026-11-21" for a pinned workspace; sunset_at is now the day the model behind the id changes.

Original source

API: pcm_16000 is 16 kHz audio from version 2026-09-30

From API version 2026-09-30, output_format: pcm_16000 returns 16 kHz audio on every synthesis route: POST /v1/audio/stream, POST /v1/audio/stream/with-timestamps and POST /v1/audio/speech.

What was wrong. On the Simba 3 models, pcm_16000 returned 24 kHz audio while the Content-Type said rate=16000. Played at the labelled rate, speech ran 1.5x slow and pitched down.

What changes for you. Nothing, until you move to 2026-09-30. A workspace or request pinned to an earlier version keeps receiving exactly the bytes it receives today, so an integration that already plays pcm_16000 at 24 kHz keeps working.

When you move your pin:

• If you feed pcm_16000 into a 16 kHz pipeline (telephony, LiveKit SIP, Twilio), it now plays correctly with no change on your side.
• If you worked around the old audio by playing it at 24 kHz, switch that step to 16 kHz, or request pcm_24000 to keep 24 kHz audio.

New workspaces start on 2026-09-30.

See the API Versioning guide for how to read and set your workspace’s pinned version.

Original source

API: simba-3.2 serves every English voice

simba-3.2 no longer requires a voice to be registered for it. Every English voice in GET /v1/voices now synthesises on it, your workspace’s own cloned voices included, and each voice’s models array lists it. Before today it served eight registered voices out of a catalogue of nearly a thousand, and any other voice returned 400.

Nothing about the request changes, and nothing you already send breaks: the eight voices built for the model are served by exactly the training they were before, and every other voice is served by the model’s zero-shot training — the same one that has served cloned voices on simba-3.2 since 2026-08-26. Which training runs is an internal routing detail; the request, the response, the latency class and the audio format are identical either way.

This is what makes the Simba 1.6 retirement on 2026-09-21 a one-line change. simba-english and simba-multilingual are switched off entirely on 2026-11-21, and the 953 catalogue voices registered for them can now move straight to simba-3.2 — an English voice — or to simba-3.0 for any other language, with no voice substitution.

curated_voices on GET /v1/audio/models is deprecated and is now false for every model. No model restricts synthesis to a registered voice set any more, so a picker that filters on the flag simply stops filtering. The field stays on the response; read english_voices_only instead, which is the one voice constraint left — a model with no multilingual training returns 400 for a non-English voice.

Original source

API: watermark verification with no credential

A new endpoint answers whether a clip carries a Speechify watermark without any credential.

POST /v1/audio/watermark/verify takes the same audio upload as POST /v1/audio/watermark/detect and returns a bare {"watermarked": true|false} — no key, no session, nothing to authenticate.

It is the API half of the public tool at speechify.ai/detect, and it exists because California’s AI Transparency Act (BPC 22757.2) requires a detection tool that is publicly accessible and invokable without visiting a website.

verify answers; detect measures. The new verb deliberately omits the confidence score its sibling returns — a public score is a gradient to optimise against. Keep using POST /v1/audio/watermark/detect with an API key when you want the score.

Because verify takes no credential, it is rate-limited per client address and draws on a shared platform budget, so expect 429 under sustained automated use. Nothing changes for an existing integration: POST /v1/audio/watermark/detect’s path, request and response are untouched.

Original source

API: watermark detection with your API key

POST /v1/audio/watermark/detect now answers, for any credentialed workspace, whether a clip carries the watermark Speechify seals into the audio it generates. This check was previously operator-only; it is now on the API and in the console. Upload the clip as audio (multipart/form-data, at most 25MB) and get back WatermarkDetectionResponse — { watermarked, confidence }, with confidence a score in [0, 1]. Nothing about the upload is stored, and no voice is read or written.

Read the answer in one direction only. watermarked: true is positive evidence the audio came from Speechify synthesis. watermarked: false is the absence of that evidence, not proof of a negative: only models redeployed since the watermark shipped mark their output, the detector needs at least three seconds of clear speech, and re-encoding or changing the speed of a clip degrades the mark. Confidence scores are comparable only between checks against the same detector version.

Detection is capped at 20 requests per hour per workspace — a forensic question, not a data-plane call.

422 watermark_audio_unusable — the clip could not be read (an undecodable container, or too little audio to judge). Deliberately not a negative verdict: “we could not tell” and “this is not ours” are different answers.

502 watermark_detection_unavailable — the detector could not answer. Nothing about the request is wrong; retry the same bytes.

The credential-free sibling POST /v1/audio/watermark/verify — a bare boolean with no confidence score — follows the next day (see 2026-08-29); use detect with an API key when you want the score.

Original source

Cloned (personal) voices synthesize on simba-3.2 for every workspace, with no enablement step. The limited release announced on 2026-08-06 is over and the per-workspace allow-list behind it is gone; you no longer need to contact us.

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 now names simba-3.2 on your cloned voices without any per-workspace condition, and driving a picker off each voice’s models array remains the right pattern. Cloning on simba-3.0, simba-english, and simba-multilingual is unchanged.

Original source

API: Projects — group resources, scope credentials, and attribute spend

The /v1/projects endpoints are now in the public API reference. A project groups the resources you create inside a workspace and the spend you incur from them, so one workspace can run several environments or several end customers without splitting into separate accounts.

Every workspace has an implicit Default project: any resource with no project lives there, and nothing you already send changes — the surface is additive and opt-in.

What a project groups:

Kind Belongs to a project Agents, knowledge bases, tools, audio assets Yes, and can be moved later Phone numbers and SIP trunks Yes API keys and service accounts Yes — a pin fixed when the credential is created Vault credentials and webhook endpoints One project, or workspace-wide Conversations, callers, batch calls, test runs, memories Yes, frozen at creation and never re-attributed Usage and spend Attributed through the calling credential’s pin Cloned voices From the pin on the creating credential — except a consent-verified clone, which is always workspace-wide The public voice and model catalog No — workspace-wide

Manage the lifecycle with POST/GET/PATCH/DELETE /v1/projects and .../{project_id}, plus archive, unarchive, restore, teardown, stats, audit, promote, and the members sub-tree (grant / revoke access). Move an existing agent with POST /v1/agents/{agent_id}/move.

Filtering: every list endpoint that takes a project accepts a project_id query parameter. Omit it to get everything you can reach, pass a proj_... id for one project, or pass the literal default for the implicit Default project. On lists whose rows can be workspace-wide — credentials, webhook endpoints and cloned voices — that literal is shared instead, because an absent project there means workspace-wide rather than Default.

Names are unique per workspace, case-insensitively; a workspace holds at most 100 live projects, and at the cap the create is refused with 409 project_limit_reached.

A project is a filter and a grouping, not a security boundary — it scopes what a credential may reach, what a scoped member sees, and where spend lands. If one team must be unable to see another’s data at all, use a separate workspace. See Projects.

Original source

API: Simba 1.6 retired at version 2026-09-21, switched off 2026-11-21

simba-english and simba-multilingual - the Simba 1.6 pair - are being withdrawn in two steps:

• From API version 2026-09-21 they are no longer selectable. Naming either returns 400 with the error code model_retired.
• On 2026-11-21 both models are switched off. From that date they are unreachable on every API version, including a workspace pinned below the retirement.

If you use either model, you have until 2026-11-21 to migrate, and for most integrations that is a one-line model change. Pinning your workspace’s API version to a date before 2026-09-21 keeps things working in the meantime with no code change at all - but it is a migration window, not an exemption, and it ends on the same day for everyone.

Why the shorter notice. Our usual sunset window is 12 months. Simba 1.6 is a previous-generation family: it cannot serve /v1/audio/stream/with-timestamps at all and runs at roughly 2.5x the time-to-first-byte of the streaming-native models. Consolidating onto the Simba 3 fleet is what lets us keep improving latency and quality for everyone, and we did not want to spend a year running two stacks to do it.

Where to go.

From To Notes simba-english simba-3.2 English. Lower time-to-first-byte, richer expressivity, streaming-native. Serves a curated stock roster plus your own cloned voices. simba-english simba-3.0 English, if you need a voice outside the simba-3.2 roster. Accepts every catalog voice. simba-multilingual simba-3.0 English, de-DE, es-ES, es-MX, fr-FR, it-IT, pt-BR. Streaming-native, and a cloned voice speaks all of them from one voice ID.

An omitted model is unaffected: it already resolves to simba-3.0.

If you synthesize outside Simba 3.0’s seven locales, simba-3.0 on its own is not a like-for-like replacement - and we are not asking you to drop those languages. Broader multilingual coverage on the current model generation is planned to be available before this date, and we will confirm the model and the timing directly rather than leave you to read it off a changelog. Talk to us so we can line your migration up with it.

If that coverage is not in your hands by 2026-11-21, we move the shutdown date rather than cut the languages off. That is the commitment; the date is not.

What changed at this version.

POST /v1/audio/speech and both /v1/audio/stream routes reject the two ids. GET /v1/audio/models returns only the models you can actually call, and each voice’s models array in GET /v1/voices does the same - so a picker driven off either endpoint stays correct without special-casing.

Read the dates off the API. While your workspace is pinned below 2026-09-21, both models still appear in GET /v1/audio/models carrying retired_at: "2026-09-21" and sunset_at: "2026-11-21". Surface sunset_at in your own tooling if you have a deadline to track.

See the API Versioning guide for how to read and set your workspace’s pinned version.

Original source

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

API: maximum-fidelity mp3, and a fix for the 22.05 kHz formats

output_format gains mp3_22050_160 and mp3_24000_160, the highest-fidelity mp3 the format can carry: 160 kbps is the ceiling at these sample rates, so there is no higher mp3 to ask for. A request for mp3_22050_192 or mp3_24000_192 was always encoded at 160 kbps, and the response now reports the mp3_*_160 it actually delivered rather than echoing the 192 back. Nothing about those two requests changes on the wire except the reported value, and no existing integration has to move.

Every mp3_22050_* format also plays at the right speed now. They were being encoded about 8% fast and close to a semitone high; if you compensated for that in your own pipeline, remove the correction. mp3_24000_*, the default for audio_format: "mp3", was never affected.

Behind both: any sample-rate conversion we do is now a high-quality resample from the model’s native 24 kHz rather than the encoder default, which keeps the audio flat to about 10.7 kHz at 22.05 kHz instead of rolling off from 10 kHz. That applies to pcm_22050, pcm_44100, pcm_48000, pcm_8000 and ulaw_8000 as well.

The two mp3_*_160 formats are produced by the Simba 3 models; pairing one with a legacy Simba 1.6 model returns 400.

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