Speechify Updates & Release Notes

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

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

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

Connect the tools you already use to Speechify Work and delegate your tasks.

Speechify Work today announced a major expansion of its integrations lineup, giving professionals a single AI workspace that can connect to the apps they already use, take on real tasks, and hand back finished work. The launch positions Speechify Work as a direct competitor to Perplexity Enterprise and Claude for Work, with a growing library of connections that let its AI agent read, write, search, and act across your stack. It marks a shift from AI as a chat window to AI as a coworker with real reach into the tools that run your day.

An AI Employee that Actually Does the Work

Speechify Work is built on a simple idea: instead of switching between a dozen tabs, you should be able to describe what you need and let AI handle it. Connect an app once, and Speechify Work can pull files, summarize threads, draft messages, update records, and produce polished deliverables like reports, decks, and spreadsheets without asking you to copy and paste anything between tools. The AI plans the steps, executes them across your connected apps, and delivers finished work back to you in the same conversation. That means less time wiring tools together and more time reviewing output, approving decisions, and moving to the next thing.

Speechify Work Integrations Available Now

Speechify Work already ships with connections to the platforms most teams live in every day, spanning cloud storage, email, calendars, team chat, ecommerce, and data analytics. Each integration lets the AI take real actions in that tool, not just read from it, so users can move from idea to done inside one workspace. The current lineup includes:

• Google Drive: Import, search, read, and create files
• Gmail: Search, summarize, draft, and send emails
• Google Calendar: Create, update, and cancel events
• Dropbox: Import, search, read, and create files
• OneDrive: Import, search, read, and create files
• Slack: Search, read, and act on conversations
• Etsy: Browse and manage your Etsy shop listings
• Amplitude: Query charts, dashboards, and product analytics
• Customer.io: Search campaigns, segments, and messaging data
• Hex: Search and run notebooks, queries, and data apps

Hundreds More AI Integrations Coming Soon to Speechify Work

The current lineup is only the starting point. Speechify Work has hundreds of additional integrations on the roadmap, spanning communication, productivity, sales, marketing, design, and developer tooling. Planned connections include YouTube, WhatsApp, Reddit, Outlook, Google Meet, Discord, Zoom, Google Sheets, Google Slides, Telegram, Salesforce, Trello, Asana, Mailchimp, Wix, Figma, Google Tasks, Todoist, ClickUp, Docker Hub, DigitalOcean, Eventbrite, Zendesk, Airtable, ActiveCampaign, and Meta Ads. The roadmap reflects the broader vision behind the product: wherever your work happens, Speechify Work should be able to reach it, whether that is a video platform, a project tracker, a CRM, an ad manager, or a design tool.

Who Speechify Work Helps the Most

Speechify Work is built for anyone whose day is spent moving information between apps, and the integrations lineup makes that especially valuable for a handful of specific audiences. The examples below show how different roles can put the same workspace to work in very different ways:

• Content creators: Pull research from Google Drive, summarize trending Reddit and YouTube threads (as those integrations roll out), draft scripts and blog posts, and schedule publishing reminders on Google Calendar without leaving one workspace.
• Marketers: Query Amplitude for campaign performance, cross-reference audience data in Customer.io, draft the next email in Gmail or Mailchimp, and hand a finished creative brief to the team on Slack in a single conversation.
• Salespeople: Read the latest Slack threads on a prospect, pull the account's Hex dashboards, draft a follow-up email in Gmail, and set the next meeting on Google Calendar so the pipeline keeps moving between calls.
• Students: Import lecture notes and PDFs from Google Drive or Dropbox, turn them into study summaries, generate practice quizzes, and listen back with Speechify's built-in voice AI while commuting or working out.
• Teachers and professors: Pull class materials from OneDrive, draft lesson plans and rubrics, generate quizzes from source readings, and send parent or student updates through Gmail without rebuilding content from scratch each term.
• Founders and executives: Summarize investor and board emails, update planning docs in Google Drive, review key metrics through Amplitude and Hex, and delegate the follow-through to the AI so the leadership hours go to decisions, not admin.
• Ecommerce sellers: Manage Etsy shop listings, draft product descriptions, pull sales trends, and coordinate customer replies without bouncing between the seller dashboard and a separate writing tool.
• Analysts and researchers: Run Hex notebooks, pull supporting data from Amplitude, and turn the results into a written brief or slide deck ready for stakeholders, all inside one workflow.
• Consultants and agency teams: Combine files from Dropbox and Google Drive, summarize client Slack channels, and produce polished decks, reports, and status updates faster than juggling a stack of point tools.
• Busy professionals in any role: Anyone drowning in email, meetings, and documents can hand routine work to Speechify Work and use the time saved for the parts of the job that actually require a human.

Why Speechify Work Matters for Knowledge Workers

Most AI tools stop at generating text. Speechify Work is designed to close the loop between thinking and doing. A marketing manager can ask it to pull last month's Amplitude data, draft a campaign brief in a Google Doc, and send it to the team on Slack in a single request. A founder can have it summarize investor emails, update the CRM, and schedule follow-ups on the calendar. A researcher can point it at a folder in Dropbox and get back a structured white paper. A sales lead can have it read Slack threads, pull the relevant Hex dashboards, and turn the findings into a pitch deck for tomorrow's meeting. The integrations turn the AI from a chat window into a teammate with real reach across the tools your work already lives in.

Speechify Work is Built for Teams that Want Fewer Tabs

The other advantage of consolidating this much capability in one workspace is focus. Every tab switch is a small tax on attention, and modern knowledge work asks people to pay it constantly. By letting the AI operate across connected apps on your behalf, Speechify Work reduces the number of surfaces you have to touch to get something finished. Voice input, voice output, and natural conversation make the experience feel less like operating software and more like handing off work to someone who already knows the systems.

The Future of Speechify Work

The long-term goal is straightforward: Speechify Work will handle all of your work. As the integration catalog grows and the underlying agent gets better at planning multi-step tasks, users will spend less time wiring tools together and more time reviewing finished output. The announcement today is a signal of that direction, and a preview of how quickly the platform is expanding to meet it. New integrations will continue rolling out on a regular cadence, with priority given to the tools users request most.

Speechify Work is available now at speechify.ai, with the full integrations list live in the app and new connections shipping on an ongoing basis.

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