Speechify Updates & Release Notes

Simba 3.5, 3.2 and 3.0 apply and

simba-3.5, simba-3.2 and simba-3.0 now apply and , which they used to accept without applying. They take the values Simba 1.6 takes, on POST /v1/audio/speech, POST /v1/audio/stream and POST /v1/audio/stream/with-timestamps.

Percent volume is relative. volume="+20%" is 1.2 times the voice’s own loudness, so volume="100%" doubles the gain rather than leaving it unchanged. Omit volume, or use medium, for no change. A gain that would clip is held under a limiter.

Pitch keeps the speed. pitch="high" raises the voice without speeding it up, and speech marks keep their timing.

Nested values multiply, as rate always has: a pitch="high" inside another pitch="high" is 1.15 times 1.15.

A whole-block wrapper costs nothing extra. A prosody that changes part of a sentence has that part synthesized on its own, as rate already does, so the sentence’s intonation can break where the value changes.

Billing is unchanged. A request is billed for its spoken text, and tags are not counted.

and <speechify:style emotion> are still accepted and not applied on these models. If you send pitch or volume today and do not want the change, remove the attribute.

No API version change is needed. See SSML.

api.speechify.ai streams from US East again

Streaming requests to api.speechify.ai (/v1/audio/stream, /v1/audio/stream/with-timestamps and /v1/audio/stream/ws) run in US East again, as they did before the evening of 17 October. Speech and voice requests keep running in the region nearest the caller.

Why. Measured from Europe, a stream’s first audio arrives sooner from US East, Atlantic crossing included.

Nothing to change. The same API key, requests and responses work. To keep one region, use us.api.speechify.ai or eu.api.speechify.ai.

See Regions.

Original source

Simba 3.5 is the recommended model

simba-3.5 speaks 48 languages under one model id, on every plan, up from the six that simba-3.0 covers. It is the model GET /v1/audio/models marks recommended from today.

One request field. Pass "model": "simba-3.5" and set language to the language of your text, for example ja-JP. Any regional variant of a listed language is in scope. See Simba 3.5 languages.

Every endpoint you use today. POST /v1/audio/speech, POST /v1/audio/stream, POST /v1/audio/stream/with-timestamps and the WebSocket at GET /v1/audio/stream/ws. POST /v1/audio/dialogue stays on simba-dialogue-1.0.

Every voice. Each catalog voice speaks all 48 languages on simba-3.5, and so does a voice you cloned on a paid plan, with the same voice ID.

The SSML you use today. , and are applied; pitch, volume, emphasis and emotion tags are accepted and not applied, as on simba-3.2 and simba-3.0.

Nothing changes unless you set it. A request that omits model still resolves to simba-3.0, and simba-3.0 and simba-3.2 stay available and are not deprecated. No API version change is needed.

simba-multilingual is served by Simba 3.5 from 2026-11-21, on every API version that can still name it. Switching to simba-3.5 before then lets you pick the voice and test it first. See Simba 1.6 and your API version.

The reference is Models.

Say names, brands and terms your way with pronunciations

POST /v1/audio/speech, POST /v1/audio/stream and POST /v1/audio/stream/with-timestamps accept an optional pronunciations list on Simba 3.5 (simba-3.5) in every language it speaks except English, which is not supported yet, and the GET /v1/audio/stream/ws input stream takes the same list in a session.pronunciations message. Each entry names a word or phrase in your input and either the IPA phones to say (ipa) or the text to say in its place (alias), and applies everywhere that text appears.

Matching. Entries ignore capitalization unless case_sensitive is true, match whole words (anywhere in Chinese, Japanese, Korean, Thai, Lao, Khmer and Burmese text), and the longest match wins. An entry overrides the model’s own pronunciation.

Limits. Up to 200 entries; text up to 64 characters and one word for an ipa entry, ipa up to 64 phones from the model’s phone set, alias up to 160 characters, and the input with every alias in place up to 20,000 characters.

Not billed. A request is billed for its input exactly as before, and speech marks still index your input.

GET /v1/audio/models lists the languages each model takes them in as pronunciation_languages.

A model or language without them returns 400 pronunciations_unsupported instead of ignoring the list. A malformed entry or a phone outside the phone set returns 400 validation_failed, naming the entry and the phone.

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

Original source

eu.api.speechify.ai and us.api.speechify.ai pin the region that runs synthesis

Two new hosts serve the text-to-speech and voice endpoints from one region: eu.api.speechify.ai from Europe and us.api.speechify.ai from US East. api.speechify.ai is unchanged and stays the default.

Only the base URL changes. The same API key, requests and responses work on every host.

A model with no capacity in the region still runs. The request goes to the nearest pool that serves the model, usually US East.

Not data residency. Your account, keys, voices, usage and logs stay in the United States on every host.

Rate and concurrency limits are counted per region. Spend limits, project budgets and your credit balance count spend from every region.

No API version change is needed. See Regions.

api.speechify.ai serves speech from the region nearest the caller

Text-to-speech and voice requests to api.speechify.ai now run in the region nearest the caller: Europe (the Netherlands) for callers closer to it, US East for everyone else.

• Every request, from today. Speech and voices moved in steps on 17 October, and streaming (/v1/audio/stream, /v1/audio/stream/with-timestamps and /v1/audio/stream/ws) followed that evening.
• All of a caller’s synthesis now runs in one region. A stream from Europe runs on the model’s capacity in Europe where it has some.
• Nothing to change. The same API key, requests and responses work. To keep one region, use us.api.speechify.ai or eu.api.speechify.ai.
• Rate and concurrency limits are counted in the region that serves each request. Spend limits, project budgets and your credit balance count spend from every region.
• Not data residency. Your account, keys, voices, usage and logs stay in the United States.

api.sws.speechify.com stops serving on 19 January 2027

api.speechify.ai is the only production host for the SpeechifyAI API. The legacy host api.sws.speechify.com keeps answering until Tuesday 19 January 2027 at 14:00 UTC. From then, every request to it gets a 308 Permanent Redirect to the same path on api.speechify.ai. This replaces the 19 February 2026 entry, which said the legacy host was not being deprecated.

• Change your base URL to https://api.speechify.ai. The same API keys, requests and responses work there.
• Using an official SDK? Upgrade it or remove the hard-coded base URL. Our SDKs have defaulted to api.speechify.ai since February 2026.
• An integration still on the legacy host stops working on that day. Most HTTP clients either do not follow a redirect on a POST or drop the Authorization header when the redirect goes to another host.
• Responses from the legacy host carry Deprecation and Sunset headers with the date, so an API gateway or SDK that reads them can warn you.

Workspaces that called the legacy host in the last 30 days get an email, and a reminder 30 days before the date.

Original source

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