What's new

What changed in Receptiva, newest first. Items are grouped by surface: API (the REST API), MCP (the connector for Claude and ChatGPT, see the Tools reference), Dashboard and Receptionist. A change is additive unless it is marked Breaking. For what is coming next, see the Roadmap.

2026-10-08 — Callback extensions in the API#

API and MCP

• New: phone_extension on leads and callback_extension on calls. When a caller gives a direct extension with their callback number, it now comes back beside the number, digits only ("12"): dial phone or callback_number, then the extension. Both are null when the caller gave no extension or there is no valid number to dial, and null when caller data is switched off for AI assistants. phone, callback_number and the caller_number filter are unchanged, except that a number followed by digits after its extension ("ext 12 3") is now null rather than a number with stray digits in it. Leads captured before this change read phone_extension: null; calls show the extension for every call processed since the earlier change today.
• A masked number shows the number's last four digits, never an extension's (from_masked on a call with no caller ID).

2026-10-08 — More accurate call summaries and lead details#

Call summaries and injury-lead details now come from a more capable model, checked against real calls before the switch. Calls processed before today keep their summaries.

Dashboard

• Callback numbers you can trust. When a caller says the number they are calling from is not the best one and gives another, the call shows the number they gave, even if they only gave part of it, instead of the number they called from. A direct extension the caller gives is kept (361-555-0147 ext. 123) in the call drawer, alert emails and Slack; a number with an extension has no one-tap call button.
• Incident dates as the caller said them. A date without a year reads "July 31, year not stated" instead of a guessed year; "last Saturday" becomes the actual date.

API and MCP

• callback_number and a lead's phone are still a dialable number or null. An extension is left off them. When the caller gave only part of a different number, they are null; from still has the number the call came from.
• incident_date in a lead's intake is YYYY-MM-DD only when the caller's words fix the day, otherwise the caller's own wording, never a year they did not give.

2026-10-08 — Settings check: a refused text stays refused, and can be appealed#

MCP

• A refusal is remembered. When receptiva_update_receptionist_draft or receptiva_apply_receptionist_draft refuses a firm fact, contact email or house rule (invalid_edit), sending the same text again (case, spacing and a final period aside) returns the same reason straight away, even after you change the firm's other settings. Change the wording instead of retrying. If you think a refusal is wrong, email hello@receptiva.ai: once reviewed and approved, that text saves for your firm.
• Fixed: a second change to a pending draft. Since 2026-09-30, a receptiva_update_receptionist_draft call that added to a draft already pending failed with "couldn't save the draft just now"; a first change and apply were not affected. Changes now add to the pending draft as documented.
• A faster check. The check on new or changed firm text runs on a newer model and answers sooner, including for a large save; on our test set it allows and refuses the same text as before.

2026-10-08 — Spelled claim numbers read more reliably#

API and MCP

• untrusted.details.references read spelled identifiers better. When a caller spells a claim or case number with words ("Q as in Quebec", "Z as in zebra"), the spelling word now decides the character, and every digit is checked against what the caller said. A number that does not check out is left out rather than stored wrong. Calls processed before today keep their details.

2026-10-07 — Structured call details#

Calls now carry the facts a case system files under a matter, as fields instead of prose.

API and MCP

• untrusted.details on every call. Who the call was about (about[] with relation, for example the client an adjuster called about), caller_organization, asked_for, message_for, best_time, and references[]: claim, policy, case and police report numbers as the caller gave them, each with a match key. On the calls list and one call's detail, REST and the connector. null on calls processed before today. Structured details.
• Find calls by claim or case number. reference= on GET /v1/calls and receptiva_list_calls matches a quoted identifier, ignoring case, spaces and punctuation. Find calls by claim or case number.
• Webhook payloads are unchanged: fetch the call to read its details.

Dashboard

• A Details block in the call drawer, and the same lines in alert emails. Claim numbers, who the call was about, the caller's company and their callback time, next to "Asked for".

2026-10-07 — Transcript paging, live firms, clearer connector copy#

API and MCP

• limit on transcripts. GET /v1/calls/{call_id}/transcript and receptiva_get_transcript take limit (1 to 500 turns), like the lists. With it, has_more and next_start_turn page the transcript; without it, nothing changes. Transcripts.
• setup.org_live is accurate. It is true for every firm that has its Receptiva number and is not suspended, and org.status reads live for them. Before, it stayed false for firms set up through the wizard.
• Connector descriptions match what it returns. receptiva_get_call names the recording link, lead_id and dashboard_url, and its text shows the caller's full number. If your assistant still says transcripts or full numbers aren't available, refresh the connector's tools in its settings.

2026-10-07 — Conversation summary details in digits#

API and MCP

• Confirmed details read like a case file. In a call's conversation summary, confirmed_details[].value now writes dates, times, amounts and other numbers in digits ("Sept 23", "about 10:45", "$733") instead of spelling them out the way the transcript does. A detail is still kept only when it was actually said on the call. Summaries written before this change are not rewritten.

Dashboard

• Same in the call drawer and alert emails. The "Confirmed in the conversation" list and the summary use digits, and name the team member who actually spoke when the phone was handed to someone else.

2026-10-06 — Full call records#

Transcripts now cover the whole call, including the conversation with your staff member after the hand-off, and each connected call gets a summary of that conversation.

API and MCP

• Three transcript segments. Each turn carries segment: intake, briefing or conversation. Breaking: speaker gains the value staff, with the person's name in speaker_name. Handle it, or request segment=intake to keep the old scope. Transcripts.
• Segment filter. segment= on GET /v1/calls/{call_id}/transcript and receptiva_get_transcript returns one part of the call; counts and paging follow the filter.
• Merged turns. Consecutive pieces of speech from one speaker are now one turn. Breaking only if you stored turn indexes as ids: they can shift.
• Transcript metadata. covers, conversation_status, connected_name, briefings and notice sit beside the turns.
• Conversation summary on call detail. untrusted.conversation_summary (summary, outcome, key points, confirmed details, next steps) and transcript_covers on GET /v1/calls/{call_id} and receptiva_get_call. Null for calls with no connected conversation or made while full call records were off. Not on the calls list. On MCP, only for the owner with full caller data on. The conversation after a transfer.
• MCP server 0.9.0.

Dashboard

• Full call records, on by default under Account & security: the conversation after the hand-off is transcribed and summarized. A second setting adds the summary to the call email and Slack alert.
• Call drawer shows the whole call, the moment it connected to your staff member, and a "Conversation with" card under the intake summary.

2026-10-05 — Webhooks, find by number, your own lead ids#

API and MCP

• Webhooks. call.completed, lead.created and lead.updated, signed and retried for about two days. Endpoints are managed by the owner under Integrations. Webhooks.
• Find by number. caller_number on the calls and leads lists.
• Your own lead ids. external_id and status_reason on leads, written with PATCH /v1/leads/{lead_id}; GET /v1/leads?external_id= finds a lead by your id.
• Clearer 400s. An unknown query parameter's error now lists the parameters the endpoint accepts.
• MCP server 0.8.0. receptiva_update_lead_status takes an optional status_reason.

2026-10-03 — Sync improvements#

API

• Reliable polling. Calls carry lead_id and processing_complete; lists carry as_of. Keep another system in sync.
• Leads list takes updated_since and call_id.
• Safe status writes. PATCH /v1/leads/{lead_id} takes expected_status and answers 409 status_conflict if the lead has moved on.
• Key introspection. GET /v1/account describes the calling key and the firm's stable id.

2026-10-02 — REST API, API keys and recordings#

• API. The REST API at https://api.receptiva.ai/v1: account, receptionist settings, calls, transcripts, leads and lead status, with an OpenAPI document. REST API overview.
• API. Call recordings: download with a key, or create a link that plays for one hour.
• MCP. receptiva_get_recording_link returns that one-hour link to the owner, with full caller data on.
• Dashboard. The owner creates and revokes API keys under Integrations. API keys.

2026-10-01 — Transcripts, full intake and firm facts#

• MCP. receptiva_get_transcript and receptiva_get_lead (the full intake) for the firm's owner, once Full caller data for AI assistants is on under Integrations.
• MCP. Calls carry the caller's number in full; receptiva_list_calls takes answered and updated_since.
• MCP. The email the receptionist gives callers and the firm facts it shares can be changed through the connector.

2026-09-30 — Developer docs and how a call was handled#

• MCP. receptiva_get_call explains how a call was routed and why, in handling and plain-English explanation.
• MCP. Receptionist settings changes through the connector: draft, confirm, apply, roll back.
• Dashboard. A "What happened" card on each call explains how it was routed.
• Docs. These developer docs went live, with Markdown copies of every page and llms.txt.

Next#

• Roadmap
• Keep another system in sync
• Tools reference