Changelog

simba-3.5, the recommended model since the 2026-10-18 entry, launches today.

• Price. simba-3.5 lists at $20 per 1M characters on Starter,$16 on Pro and $12 on Scale, twice the rates of `simba-3.0` and `simba-3.2`. Until 21 November 2026 it bills at their rates instead:$10, $8 and$6.
• Announcement. The switch from simba-3.2, the full list of 48 languages and how a voice sounds in each are in the Simba 3.5 announcement.
• Staff picks. In GET /v1/voices, each language’s staff-pick voices now carry staff_pick_rank, 1 for the first pick of its locale. Simba 3.5 sounds best with a voice native to the language you generate, so start with these. The full table is on Language support.

Simba 3.5, 3.2 and 3.0 apply <prosody pitch> and <prosody volume>

simba-3.5, simba-3.2 and simba-3.0 now apply <prosody pitch> and <prosody volume>, 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.

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. <break>, <prosody rate> and <sub alias> are applied; pitch, volume, emphasis and emotion tags are accepted and not applied, as on simba-3.2 and simba-3.0.

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.

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 <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 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.

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.

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.

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.

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.

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.

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.

The consent form field on POST /v1/voices is switched off, on every API version, whatever your workspace is pinned to. Creating a cloned voice now requires proof that the speaker agreed: a consent challenge, and a recording of the speaker reading the phrase it issues. This is the switch-off the 2026-08-13 entry announced and said would be dated here.

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 ids are served by our current models instead of their Simba 1.6 training. They keep answering on every API version that can still name them; what changes is the model behind the id, not your integration.

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.

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.

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.

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.

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.

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.

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.