Speechify Release Notes

API: the 20,000-character limit on the stream endpoints counts spoken text, not SSML tags

POST /v1/audio/stream and POST /v1/audio/stream/with-timestamps now accept up to 20,000 characters of spoken text, the characters a request is billed for. SSML tags no longer count toward the limit, as on /v1/audio/speech since 9 Oct.

The number is unchanged; only what it counts is. Tags such as , , and are not counted, an entity such as & counts as one character, and a counts its alias.

The input as sent can be up to 32,000 characters, markup included.

A refusal says which limit it hit. It is still 400 validation_failed, and the message names either the spoken-text limit or the 32,000-character ceiling.

Nothing that was accepted before is refused. Plain text is counted exactly as before.

/v1/audio/speech is unchanged: 2,000 spoken characters, and up to 20,000 as sent.

No API version change is needed. See API Limits.

Original source

POST /v1/audio/speech now accepts up to 2,000 characters of spoken text, the characters a request is billed for. SSML tags no longer count toward the limit.

• The number is unchanged; only what it counts is. Tags such as <speak>, <break>, and <prosody> are not counted, an entity such as & counts as one character, and a <sub> counts its alias.
• The input as sent can be up to 20,000 characters, markup included.
• A refusal says which limit it hit. It is still 400 validation_failed, and the message names either the spoken-text limit or the 20,000-character ceiling.
• Nothing that was accepted before is refused. Plain text is counted exactly as before.

/v1/audio/stream and /v1/audio/stream/with-timestamps are unchanged: 20,000 characters, SSML tags included.

No API version change is needed. See API Limits.

Original source

API: stream text into speech over a WebSocket

GET /v1/audio/stream/ws is a new WebSocket endpoint for text that arrives in pieces, such as a reply an LLM streams token by token. Send the text as you receive it, and the API speaks each sentence once it is complete, returning Base64 audio and, with speech_marks=true, word timestamps on one timeline.

Authenticate the upgrade with Authorization: Bearer. The settings ride the query string under the POST /v1/audio/stream names, and a refused setting, voice or plan limit is an ordinary HTTP error before the upgrade.

Each segment is one synthesis. It is billed, rate limited and moderated as one POST /v1/audio/stream request, and the voice’s prosody starts afresh at each segment.

A session holds one concurrent request. It ends after 60 seconds with nothing to speak, and stops taking text after 5 minutes.

Server-side only for now. A browser cannot set the Authorization header on a WebSocket.

No API version change is needed. See Streaming Text Input.

Original source

POST /v1/voices and POST /v1/voices/consent-challenges now return 403 voice_cloning_unavailable_in_region for a request from a jurisdiction where voice cloning is not available.

• Location is the IP address that sends the request. When your backend calls the API, it is your server’s location, not your end user’s. A location header in the request is ignored.
• Nothing is spent. The refusal comes before consent verification, so a consent challenge you already hold stays usable until it expires.
• Not retryable from that location. No API key, role or plan change lifts it, and it is never stored against an Idempotency-Key.
• Everything else is unchanged. Listing voices, synthesizing with them and deleting them work from anywhere, cloned voices that already exist included.

No API version change is needed. See Where voice cloning is available.

Original source

POST /v1/audio/speech, POST /v1/audio/stream, and POST /v1/audio/stream/with-timestamps accept an optional safety_identifier: a stable, opaque id for the end user of your application on whose behalf the request is made.

Send it when many of your own users share one workspace. Abuse can then be attributed to, limited for, or blocked for that one end user instead of your whole workspace.

• Send a hash, never personal data. The field takes 1 to 64 characters of letters, digits and . _ - : | + / =, so an email address is rejected with 400 validation_failed. A keyed hash of your internal user id is the recommended value.
• It is metadata, not content. It is recorded with the request even under zero data retention.
• Per-end-user limits can be set for your workspace, nested inside its own limits. Over one, a request returns 429 naming the safety_identifier.
• A blocked end user returns 403 safety_identifier_blocked. Your other end users are unaffected.

Omitting the field changes nothing. No API version change is needed. See Safety Identifiers.

Original source

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