What's new

This page tracks changes to the public developer contract and its documentation. A date is the day the item was documented or confirmed here; it is not the original product launch date unless the entry explicitly says so.

October 19, 2026#

null resets conversation timing to its defaults#

• PATCH /assistants/{id} now accepts null on endpointingPlan, turnDetectionPlan, vadPlan and interruptionPlan under settings.conversationConfig, and on every field inside them. The API deletes the stored value and the next call uses the default. Before, null returned 400 and a value, once set, could not be removed.
• The timing table now lists each field's default, so you can see what you are changing from.
• Two places already accepted null and stored it as a value: expressiveOptions, and individual keys inside ivrSettings. They now delete the key instead, so a later GET leaves it out rather than returning null. A call treats a missing key and a null one the same way, so nothing changes on calls.
• No migration.
• Guide: Conversation timing.

October 5, 2026#

Transcriber testing#

• Flag a caller line the call's transcriber got wrong and type what was actually said. The line's audio is replayed through the candidate transcribers you choose, and each is scored against your text: an exact match after normalizing case and punctuation, and a word error rate.
• Group candidates into banks, up to eight per bank, and read each bank's accuracy per transcriber, its leader and whether the leader clears your threshold, over a window of up to 90 days. Every flag brings zero to two unflagged control lines from the same call, so a candidate that breaks ordinary lines cannot win on hard ones alone.
• Before switching, start a full-call run, usually from a flagged call: the candidate replays every caller line with audio timing in up to ten calls, the results are compared with the stored live transcript, a judge labels each difference and writes a verdict, and a sample of up to 120 lines is set aside for a person to check. The results cards, each bank's turn table and each run's lines export as CSV.
• Routes: /turn-flags, /transcriber-banks, /full-call-runs and GET /organization/tenants. They take an organization API key without X-Tenant-Id; tenant keys are refused with 403 ORG_SCOPE_REQUIRED. GET /transcribers and GET /transcribers/{id} now also accept an organization key without X-Tenant-Id, and every transcriber carries a language.
• Two ways to use it. Organization admins work in the dashboard: Flag for transcription on a call page, and Transcriber tests in the sidebar for results, flagged lines and full-call runs. Or build the same screens into your own product on the API.
• No migration. Nothing changes on live calls or assistants.
• Guides: Transcriber testing, Test transcribers in the dashboard and Build a transcriber testing UI. Reference: Transcriber Tests API.

October 1, 2026#

Text tests run the configured model only, and refuse speech-to-speech models#

• A text test run now talks to the assistant on its configured model and nothing else. Before, a model that could not answer was quietly replaced by another model for the rest of the run, so a pass did not prove the model you ship. Now such a case ends in error with the provider's message.
• POST /test-suites/{id}/run returns 400 with VALIDATION_ERROR when the suite's assistant runs a realtime model (speech-to-speech, such as gpt-live-1). The message names the model. Nothing is queued or billed. The dashboard shows the same message when you click Run suite.
• Migration: suites aimed at a GPT-Live assistant have been producing results that came from a different model. Treat those runs as not having tested GPT-Live. To keep testing the prompt in text, point the suite at an assistant on a chat model with the same prompt and tools. To test the voice model itself, place a real call.
• Guides: Testing, Run text tests and GPT-Live 1.

September 25, 2026#

Show your assistant's number on transfers#

• transferSettings takes a second knob, use_assistant_number. When true, the person answering a cold, warm or warm-return transfer sees your assistant's phone number (the number the customer dialled) as the caller ID, instead of the customer's number. Set it on POST /assistants or PATCH /assistants/{id}; GET returns it.
• No migration. It defaults to off, and an assistant without it transfers exactly as before.
• With it on, your team's phone no longer shows who is calling. The whisper on a warm or warm-return transfer still briefs them, and customer_number stays on the end-of-call report.
• transferSettings deep-merges, so setting this knob leaves amd_detection as stored. In the dashboard it is the Show Assistant Number on Transfers switch under Call Settings.
• Guide: Caller ID on a transfer. The generated API reference picks up the new key with the next refresh of the public specification.

September 24, 2026#

Realtime models: GPT-Live 1#

• The model catalogue now carries a type on every entry from GET /models: chat for the pipeline models, realtime for speech-to-speech models that hear the caller and speak back themselves. The first realtime model is gpt-live-1.
• An assistant on a realtime model keeps its stored prompt (it runs on the model's reasoning backend, tools included) and can optionally set voicePersonaPromptId, a prompt of the new voice_persona type, to control how the voice sounds and behaves. The assistant's voice, transcriber and speech delivery settings are ignored on such calls.
• Five per-call override keys tune it: voice, backendModel, reasoningEffort, serviceTier and maxSessionDuration. They are camelCase, and the GPT-Live 1 page states the rules, including the one behavioral difference that matters most: scripted lines are conveyed in the model's own words, not read verbatim.

September 23, 2026#

Separate tool instructions for text conversations#

• A tool can now carry textInstructions next to instruction: the same shape (title, description, steps), used instead of instruction when the assistant is in a text conversation over SMS, WhatsApp or web chat. Voice calls always use instruction. Set it on POST /tools and PUT /tools/{id}; GET returns it.
• No migration. A tool without textInstructions behaves exactly as before in every channel, so nothing changes until you add them. On PUT /tools/{id}, leaving the field out keeps the stored value and null removes it.
• Per-assistant overrides for the text version have their own endpoints, each mirroring a voice one: PUT and DELETE /assistants/{id}/tools/{toolId}/steps/{stepId}/text-override, PUT /assistants/{id}/tools/{toolId}/text-description-override, and GET and DELETE /assistants/{id}/tools/{toolId}/text-override. Voice and text overrides are independent, and a text override only applies while the tool has textInstructions.
• The Knowledge Base tool follows the same rule: PUT /tools/{id}/instruction takes an optional textInstructions for your tenant's copy.
• Guides: Custom tools, Instruction overrides and Control when the assistant looks up. The generated API reference picks up the new field and routes with the next refresh of the public specification.

September 22, 2026#

Send an SMS from your own number#

• Added POST /sms. Send one text from a phone number registered on your tenant. You supply fromNumber, toNumber, and message. The number you send from must belong to the same tenant as the API key.
• A number that is unknown, deleted, or owned by another tenant returns 404 with RESOURCE_NOT_FOUND. Those cases look the same, so the response does not reveal whether the number exists.
• The body cannot be empty and cannot be longer than 1600 characters. A successful send returns data.messageSid.
• This is separate from in-call SMS, where the assistant texts the caller during a voice call. Guide: Send an SMS. Reference: SMS API.

September 16, 2026#

Text test suites#

• You can now put a scripted caller in front of an assistant as text: create a suite, add up to twelve cases, run the folder, and poll until passed, failed, or error. There is no phone call, no speech, and no row in call history. Knowledge-base lookup still runs; other tools are mocked.
• Routes: /test-suites and /test-runs. v1 accepts mode: "text" only. voice is 400.
• A case can seed prior turns, mock tools by their product names, and add typed checks (tool_called, tool_not_called, extract). The suite passes only if every case passes the judge and every required check.
• Set iterations from 1 to 10 to run every case that many times in one run. A case passes only if all of its attempts pass, which is how behaviour that only shows up sometimes gets caught.
• Token use for a run is billed on its own Tests line, not folded into Calls.
• Results arrive while the run is still going, a case at a time, so a long run shows progress rather than nothing until the end.
• Guides: Testing and Run text tests. The generated API reference picks up the tags with the next refresh of the public specification.

September 14, 2026#

Integrations, starting with Raindrop#

• New Integrations section. An integration connects an OnCore tenant to a third-party product you hold the account for: you sign up with the provider, create an API key there, and paste it into OnCore. One key covers the tenant you connect it in. Your data lands in your workspace and your usage is billed to you by them.
• Raindrop is the first one. It is monitoring and observability for AI agents, and once connected every completed call arrives in your own Raindrop workspace within seconds of the caller hanging up, where signals, issue detection and stumbles surface the conversations worth reading.
• Connect it under Platform, then Integrations, then Raindrop in the dashboard. The key is checked with Raindrop before it is stored, so an invalid or revoked key is refused at that moment rather than failing quietly later.
• Each call carries its transcript, its summary, and call metadata: the caller's number, the number they dialled, the assistant that answered, the models it ran on, the duration and the reason the call ended. Events are attributed to the assistant rather than the caller, so Raindrop's per-user counts read as your assistants. Audio recordings are not sent.
• Delivery starts when you connect, and existing call history is not backfilled. Every assistant in the tenant you connect is included automatically, including ones created later, so connect each tenant whose calls should be delivered.

September 11, 2026#

WhatsApp text channel#

• An onboarded WhatsApp number can now answer inbound text, not just voice calls. In the dashboard, finish Sign up to WhatsApp on the assistant, then turn WhatsApp Enabled on under Messaging. PATCH /assistants/{id}/whatsapp-enabled is the same switch for your own UI.
• Enabling fails with 400 if the assistant has no linked number, or if that number was never onboarded to WhatsApp.
• OnCore answers customer-initiated text only. It does not send templates, start a chat, or reply to stickers or images. Threads land on conversations with channel: whatsapp.
• WhatsApp and Create and configure carry the curl and the precondition. The onboarding flow is unchanged.

September 10, 2026#

MCP server: manage assistants from an AI coding agent#

• Added the MCP server, which lets an AI coding agent read and change your OnCore configuration on your behalf. It implements the Model Context Protocol, so it works with Claude Code, Claude Desktop, Cursor and other MCP clients. It runs as a subprocess of your client on your own machine and talks to the public API over HTTPS with your own key.
• Install is one command and one variable: claude mcp add oncore -e ONCORE_API_KEY=YOUR_API_KEY -- npx -y @oncore/core-api-mcp. Everything else defaults, including the environment, so there is nothing to clone and nothing to build. Node.js 20 or newer.
• Tools and write safety lists all 18 tools. They are shaped around tasks rather than endpoints, so get_assistant can resolve the prompts, tools, documents, task groups and phone number of an assistant in one call, and two generic tools cover the ten configuration resources between them.
• Writes are on by default and confirmed before they apply. A change to anything a live assistant uses returns a preview of current state against resulting state plus a single-use token, and applies only when called again with it. The token is bound to the exact arguments it was issued for, so a preview of a small change cannot be used to apply a larger one.
• ONCORE_WRITES=off removes the write tools altogether rather than refusing them. That is the setting to use when an agent should read production configuration and have no path to changing it, because the tools are not registered and the agent has no way to know the capability exists.
• Assistant tool, dictionary and phone-number links are managed only through link_assistant, never through update_assistant. Those fields replace the whole set on the API, so a partial list sent through a general update would silently drop the links it omitted. update_assistant does not accept them at all, and link_assistant reads the current set before applying an addition or removal.
• update_resource is always partial. Several of the underlying routes replace the whole record; the server reads it first and resends what you did not mention, so you do not have to know which routes behave which way.
• Some capabilities are unreachable by design rather than undocumented, with no flag that enables them: anything administrative, releasing or buying a phone number, anything acting on a call in progress, and anything that starts a metered session. Ask the agent to call whoami for the current list with a reason attached to each one.
• Results are pruned rather than passed through, because an agent has a limited context window. List rows carry summaries with long text replaced by its length, transcripts and message histories come back in windows with a pointer to the next, and the voice catalogue drops the provider-specific configuration that makes up most of its size. Filtering a query is free and materially improves what the agent can reason over.

September 7, 2026#

Session insights for calls#

• Added GET /calls/{id}/insights and GET /calls/insights?ids=.... They return the models that served a call, one performance entry per assistant turn (end-to-end latency, LLM time to first token, TTS time to first byte, transcription and end-of-utterance delay, token counts), a summary with averages, and a timeline of caller speech, assistant replies, tool calls and tool results. It is the data behind the dashboard's Session Insights panel.
• The batch endpoint takes 1 to 25 unique call ids as a comma-separated ids query parameter and reports each miss as call_not_found or metrics_not_found, so one unknown id never fails the request.
• Metrics land shortly after a call ends. Until then the single endpoint answers 404 with Call insights not found while GET /calls/{id} already returns the call. Guide: Read session insights. Reference: Calls.

September 3, 2026#

Speech delivery: expressive mode, emotion tagging, and Eleven v3 tags#

• Added walkthroughs for the three ways an assistant can sound less flat: Expressive mode, Emotion tagging, and Eleven v3 audio tags. deliveryMode itself was already on Create and configure an assistant. These pages are the how-to and the tag catalogue.
• Expressive mode lets the model steer delivery on Cartesia, Fish Audio, xAI, and Inworld. The new page lists expressiveOptions, what each voice family can actually render, and why delivery instructions belong in instructionsAppend rather than the prompt.
• Emotion tagging injects at most one tag per English reply on Cartesia Sonic 3 / 3.5 / 3.6 and ElevenLabs eleven_v3. The page now publishes the closed tag set OnCore writes, and the cases that stay untagged (greeting, short sentences, non-English).
• The Eleven v3 page separates that closed set from ElevenLabs's own non-exhaustive catalogue (voice, pacing, reactions, accents, sound effects), checked against ElevenLabs's prompting guide on 3 September 2026, and says when you can write [tag] yourself (deliveryMode: "none", or in firstMessage).

IVR router mode#

• Added IVR router mode: set ivrSettings on an assistant so a short router answers first, then transfers the caller on one of the assistant's transfer reasons or hands the call to the full assistant mid-conversation. The full assistant introduces itself, acknowledges what the caller told the router, and continues in its own voice, model, prompt and toolset.
• Router scripts are a prompt type. POST /prompts with "type": "ivr" creates one and GET /prompts?type=ivr lists them. Three placeholders, {assistant_name}, {transfer_instructions} and {handoff_tool_name}, are filled in when the call starts.
• ivrSettings merges per key on PATCH, so { "ivrMode": false } switches the router off without discarding the prompt, voice, model and greeting. "ivrSettings": null clears the whole object, and a key sent as null reads as unset.
• Router mode fails open. A missing or wrong-type router prompt, or a voice that no longer exists, produces an ordinary call rather than a broken router.
• Capabilities and availability still lists ivrSettings as preview. The generated assistants reference picks up the keys with the next refresh of the public specification.

Six new models in the provider catalogue#

• Two Gemini models joined the Gemini page: gemini-3.6-flash and gemini-3.7-flash. They take the same settings on the same route as the four already there, so a per-call override written for gemini-3.5-flash is accepted on both. Every key in that page's table except maxTokens was measured on both new models, out-of-range values included. Both penalties are refused outright at every value, in-range ones too, where LiveKit's own reference implies an unsupported parameter is silently stripped instead, so that page now keeps them out of its settings table and says plainly not to send them. stop works, and its real cap is five sequences rather than the four published for xAI. The difference that matters is when each thinks. gemini-3.7-flash thinks on every turn even with reasoning_effort left out, and gemini-3.6-flash does not think at all until you set it, which changes how much token headroom each one needs.
• A tight token limit on gemini-3.7-flash can cost you the whole reply. At a 30 token limit it spent the budget thinking and returned no visible output at all, so the caller hears silence rather than a short answer. An ordinary two-sentence turn spends 573 tokens there with nothing set, so budget in thousands rather than hundreds; the 2000 token floor that page recommends was measured on the older Gemini models rather than on this one. The thinking budget section carries the measured numbers for both models.
• Added grok-4.6, the first xAI language model in the catalogue. It is one of the models that genuinely applies temperature: a negative value is refused rather than swallowed, and xAI says why. The catch is the top of the range. At 2, which LiveKit publishes as the ceiling, the request comes back with no content at all and the caller hears dead air, so OnCore now caps temperature at 1.5 on this model and lowers anything higher rather than sending it. reasoning_effort: low costs less than leaving the key out on this model, not more.
• nova-3-medical is now documented on the Deepgram Nova page alongside nova-3 and nova-2, which is where Dictionaries has been pointing. It takes the same transcriber body, and it is English-only. It refuses keywords, the term-boosting parameter belonging to nova-2, so a nova-2 transcriber body carried across unchanged fails every call on it. Two things about it read backwards: it publishes en-CA and en-IE where nova-3 publishes neither, and it is absent from LiveKit's colocated-deployment list, so an assistant serving callers in India gives up the colocated Deepgram deployment by choosing it.
• Added gemini-3.5-transcribe-live, the first Google transcriber in the catalogue. It takes customVocabulary and languageCodes, and it is the one model on the platform that ends the session over a key it does not recognise, which is why OnCore sends it those two keys and nothing else. A stray key in a transcriber body is discarded before it can reach Google rather than ending the call, so what you lose is the setting.
• Added mistv3, the first Rime voice model in the catalogue. Read the speed warning before setting anything: measured live, speedAlpha runs the opposite way round from the direction LiveKit's parameter table publishes for mistv3 itself, so below 1.0 is slower and above 1.0 is faster, while inlineSpeedAlpha on the same model measured the other way round again. LiveKit publishes no direction for that one at all, so the two speed controls on this single model run in opposite directions.
• Guard columns on these pages say what a provider did with a bad value where that was measured against the provider on September 3, 2026, and say Not measured where no such value was ever sent. Two behaviours are new in that column. Refused, failover answers is the language-model case, where the rejection never reaches the caller because another model answers the turn; it replaces Refused, call fails on every language-model page, which described a failure that does not happen on that route. Lowered to the ceiling is a value the platform caps below the published range. Caveats separate the two the same way, and name the provider's published parameter table where a fact comes from there rather than from a call.

Per-call provider settings: the wider published surface#

• A key OnCore does not model is not discarded. The provider pages previously said an unlisted key in a per-call override was dropped before it left the platform. On the providers reached through the LiveKit Inference gateway OnCore forwards it exactly as you spelled it, though the gateway itself accepts only the keys it publishes for that model, so an unpublished key still stops there. The exception is the Google transcriber, which ends the session over a key it does not recognise, so OnCore narrows what it sends there. Providers reached through their own client rather than the gateway (ElevenLabs, Cartesia text-to-speech, Speechmatics) take fixed settings and carry nothing extra, which each of those pages already says. The Deepgram Nova page now documents the rest of the published Nova surface that reaches Deepgram this way, including redact, profanity_filter, dictation, replace, tag and version, along with the ones that turn out to do nothing useful on a live call (detect_language, search and utterance_end) and the two OnCore now refuses outright (channels and vad_events, either of which costs you the call); the two near-miss spellings that go nowhere (tags for tag, mipOptOut for mip_opt_out); and the one published key that does not reach Deepgram at all (diarize).
• redact is the one of those with real consequences. It changes the transcript itself, so a card number or a social security number redacted there never reaches your end-of-call report, your webhooks or your own systems, and one that is not redacted reaches all three.
• Language-model settings are per-call only. A model in your catalogue stores the model id, temperature and maxTokens and nothing else, so every other setting on a language-model page reaches the provider through the overrides.model.settings object in your assistant-request response, or not at all. Both language-model pages and the providers introduction now say so, rather than implying a stored value the key could fall back to.
• keyterm is now documented as a per-call setting on nova-3 and nova-3-medical, alongside the assistant-level dictionary route, for terms that are only right for one call.
• grok-4.6 gains tool_choice, and documents seed, logprobs, top_logprobs, stop and both penalties. tool_choice works, with the caveat that required means the turn cannot end without a tool call, so the model will invent an argument to satisfy it. The other five were each measured doing nothing at all on this model, stop included, which is worth knowing before you rely on the published four-sequence cap that never trips.
• The Google transcriber page gains its published 26-language list, the published caps on both of its settings, and what it does not return. Read that last part before you gate on it: there are no speaker labels, words comes back as an empty list rather than absent, and confidence is present but pinned at 1 on every result, so a confidence threshold silently passes everything.
• The Gemini page gains the published thinking budgets behind reasoning_effort (1024, 8192 and 24576 tokens) and a warning about thinkingLevel, which is Google's own key for the same thing and not the one this route takes.
• Where a language-model page said an unrecognised key was "rejected before the request is sent", that guard is LiveKit's rather than OnCore's. The warning is unchanged in substance: a typo still costs the turn, and automatic failover still answers it from a different model.

September 2, 2026#

Watch a live call, and step into it#

• Added Live monitoring: list the calls in progress with GET /calls/live, mint one browser join credential with POST /calls/{id}/monitor-session, then take over or end the call. The REST half is available now; @oncore/live-call-sdk, the browser half, is preview and is not on a public registry.
• Two things are yours rather than OnCore's, and the guide says so before it shows any code. Which of your staff may listen is enforced in your backend before it calls us, because an API key carries a tenant and nothing else. And disclosing live monitoring to callers is your obligation; the guide offers firstMessage as the cheap mechanism. actorLabel is recorded verbatim on the audit record and is never treated as an identity.
• Stated the v1 limits a compliance review asks about: the person who takes over is not transcribed (the stored transcript carries a labelled marker where they spoke, not their words), and the recording stays a single mixed track with no way to separate their voice from the caller's afterwards.
• Documented what the transcript does during a takeover, because a panel has to be designed around it. The caller keeps being transcribed throughout. What stops is the assistant's voice and the assistant's own transcript, together. So a live panel shows the caller's words and the supervisor's side as a gap.
• Documented what the caller hears at each step, including that ending a call after a takeover skips the assistant's goodbye, and that the bridge and resume lines are fixed in v1 rather than per-assistant settings.
• Added GET /calls/{id}/monitor-sessions, the audit read path: who held a monitor session on a call, the actorLabel their backend attached, and when they took the call over. It answers during the call and after it has ended.
• Every path takes id, the call's identifier in the API, and every response echoes it as id. callId is the separate identifier the assistant records for support correlation, appears on the same live-calls row, and is never accepted in a path.
• Documented the one 409 reason worth retrying. agent_absent means the call is live but the assistant is out of the room for a moment, which happens when it reconnects mid-call, so retry it once or twice with a short delay. not_live is final and must never be retried. A client that treats the two alike shows "this call has ended" to a supervisor who is still listening to it.
• Added DELETE /calls/{id}/monitor-session, which closes one monitor session and does not end the call. Call it when your panel goes away, with fetch(url, { method: "DELETE", keepalive: true }) so it survives the page unloading; navigator.sendBeacon cannot send a DELETE. An open session holds a per-call monitor slot until its token lapses, and mint-time release is the backstop, so a lost close costs a few minutes rather than correctness. Do not build retries around it.
• Inverted the microphone guidance. The SDK now absorbs the permission race just after takeover on a bounded budget (micPermissionRetryMs), so a retry of your own would compound with it. mic_requires_takeover surfacing at all now means the takeover genuinely has not happened, which makes it a bug to fix rather than a condition to handle; the cost is that this mistake takes about a second to report instead of failing instantly.
• Answered the reload question: a supervisor who refreshes their panel carries on, whether they were listening or mid-takeover, without consuming a per-call monitor slot and without the caller hearing a second bridge line.
• Errors now covers the 409 conflict body and its closed set of reason codes, and Rate limits covers the per-tenant 429 on minting monitor sessions, whose cooldown is a top-level retryAfterSeconds rather than an envelope field.
• Capabilities and availability lists live monitoring as available and narrows the old "no official SDK" entry: there is still no drop-in widget and no general-purpose REST SDK.
• Migration impact: none. Every endpoint, field, and error body here is new, and no existing response shape changed.

Knowledge Base when-to-call text reaches the assistant#

• Documents still turn lookup on. OnCore provides one Knowledge Base tool; you do not create, rename, or delete it. Linking it on an assistant opts that assistant into when-to-call instructions. Assistants that do not have it linked keep the original lookup.
• You can set when-to-call text for one assistant with PUT /assistants/{id}/tools/{toolId}/description-override, or change the tenant default with PUT /tools/{id}/instruction against the Knowledge Base tool id. An empty description restores both default lines.
• When assistant when-to-call text is set, the assistant is told that sentence plus Call kb_lookup, then answer from what it returns. The previous default numbered step is removed, so leftover "look up any assistant-specific fact" no longer stays in the prompt.
• Guide: Control when the assistant looks up. Dashboard: assistant → Knowledge Base → When to look this up, after the tool is linked on the Configuration tab.

Capture forms can be edited in the dashboard#

• Added Edit forms in the dashboard, covering the Capture Forms tab on an assistant, the question editor, the placeholder picker, and the preview of the email and text message. The editor calls the same endpoints as the API, which remains the surface to automate against.
• Capture forms no longer presents the REST API as the only way to configure a form.
• Stated plainly that an image used in emailBodyTemplate must already be hosted and be referenced by absolute HTTPS URL. There is nowhere to upload one to OnCore and the delivered email carries no attachments. See Images must already be hosted.
• Added Build it into your own product for resellers putting form editing behind their own UI: the tenant pattern, the derivable placeholder list, and the validation errors worth showing a person.

September 1, 2026#

Cartesia Sonic 3.6#

• Added sonic-3.6, the current Cartesia generation and the default choice for Cartesia voices. It speaks 44 languages, two more than sonic-3.5, and takes the same speed, volume and emotion settings, so a per-call override written for sonic-3.5 carries over unchanged.
• Sonic 3.6 supports the emotion_tagging delivery mode on English calls, and now appears in the supported list on Create and configure an assistant.
• sonic-3.5 and sonic-3 stay documented and fully supported, so an assistant already running on either needs no change. The phoneme table on Dictionaries and recognition terms now links all three.

Dictionary language is an allow-list, not free text#

• language on a recognition term or pronunciation must be one of the codes a live call can settle on: en, fr, de, es, it, pt, ar, nl, hi, ru, ja. Omit it (or pick All languages in the dashboard) and the entry applies on every call.
• A locale such as en-AU is stored as the base code (en). A name (french, english) or a code the detector cannot settle on (ko, zh) is a 400, not a silent no-op.
• The allowed codes and when each kind of entry uses the tag are on Dictionaries and recognition terms. Create and update examples stay on Manage dictionaries.

August 31, 2026#

Dictionaries: phonemes on Cartesia sonic-3.6, and how accent affects them#

• Dictionaries and recognition terms now lists sonic-3.6 alongside sonic-3 and sonic-3.5 as a Cartesia model that speaks phonemes. A phoneme rule on a sonic-3.6 voice previously fell back to the entry's respelling instead.
• Clarified that phonemes are read with the accent of the voice speaking them, so a rule that is only correct in one language needs a voice in that language. An entry's language decides when a rule applies, never how it sounds.
• Corrected what language does on a recognition term: it applies only when the assistant's transcriber is set to a single language. On a multilingual transcriber every term is sent whatever its tag says, so scope terms by keeping them in separate dictionaries and linking only the ones an assistant needs.
• Documented the combined recognition-term limit: the first 100 terms across an assistant's own entries and every dictionary it links are sent, counted in linking order.

August 28, 2026#

Dictionaries and recognition terms#

• Added Dictionaries and recognition terms, covering how recognition terms and pronunciations work, how tenant lists combine with an assistant's own entries, and which voices and transcribers apply each rule rather than ignoring it.
• Added Manage dictionaries for creating a dictionary, linking it in precedence order, and confirming on a call that a rule took effect.

August 18, 2026#

Capability discovery#

• Added Capabilities and availability, the canonical answer for what the public Core API supports and what it does not.
• Added a reseller-first path that explains organization keys, tenant isolation, and the public tenant-lifecycle boundary.
• Restored homepage links for WebRTC, web chat, transfers, webhooks, and tool proxy documentation after the underlying docs were reorganized.

Browser calling#

• Expanded Browser calling with WebRTC into a complete server-and-browser integration with session creation, microphone handling, disconnect cleanup, and user-facing failure states.

Machine-readable documentation#

• Added generated Markdown twins for API endpoint pages.
• Added an API-specific LLM bundle and included the generated reference in the full bundle.

Available now, regardless of documentation date#

Browser WebRTC calling, cold/warm/warm-return transfers, dynamic transfer routing, web chat, inbound SMS, in-call SMS, WhatsApp voice and text, custom tools, knowledge documents, capture forms, task groups, recordings, transcripts, and organization-key tenant access are all available public developer capabilities.

For the precise boundary and the entry point for each feature, use Capabilities and availability. The generated API reference remains the source of truth for fields, methods, paths, and response schemas.

Next steps#

• Capabilities and availability - check whether a planned integration has a supported public surface.
• Versioning and stability - build clients that tolerate additive API changes.
• API reference - inspect the current generated contract.