Changelog

Added

Live call lifecycle events — call.status_changed

A new account event, call.status_changed, fires the moment a call moves through its lifecycle — Queued → Ringing → In-Progress → Terminated — so you can react while a call is happening instead of learning about it only when it ends. Each event carries the state entered (status {state, label}), the state left (previousState), and — on termination — the terminationType (completed, busy, no-answer, failed, canceled), mirroring the status object the calls API already returns.

The event arrives on every surface the stream reaches: dial wait-for call.status_changed, the SDK event connections, and webhooks (eventTypes: ["call.status_changed"]). The Terminated transition intentionally coincides with call.ended, which remains the terminal snapshot carrying durationSeconds and transcriptAvailable — see the event page for how the two relate.

Reply and react to messages

Reply to a message — POST /api/v1/messages/{messageId}/reply — sends a threaded reply (body) or a reaction (reaction: love, like, dislike, laugh, emphasize, question, or a single emoji) targeted at an existing message. The sender is derived from the target message, so the reply always stays in that conversation. On iMessage numbers replies thread and reactions are native (Tapbacks); recipients that can only receive SMS get emoji reactions as a regular text.

The Message resource and the message.received event now carry replyToId and reaction, so inbound threaded replies and reactions on iMessage numbers are linked to the message they target.

Available everywhere: dial message reply in the CLI, replyToMessage / reply_to_message in the Node and Python SDKs, a reply_to_message tool in the agent SDKs (LangChain, AI SDK, CrewAI, AutoGen, Agent Framework), and on the MCP server.