Copy page

What's New

2026-09-28

MCP OAuth compatibility: Fixed an authorization-discovery issue that prevented Python MCP SDK 2.2.0 clients from reaching browser sign-in. Fresh OAuth authorization and call planning have been verified in production. (#155)

Agent-plugin call monitoring: Updated Claude, Codex, and Cursor plugin instructions recognize both no-answer status formats and follow server-directed polling and stop instructions. They also require user confirmation before retrying a call. (#770)

2026-09-24 — Updated Billing

Updated billing model: Model Fee is $0.0296 per 10 seconds for One-shot-call and $0.0148 per 10 seconds for Goal. US / CA domestic outbound Carrier Fee is $0.0400/min and $0.0200/min, respectively, rounded up to whole minutes; international charges follow carrier rates and billing increments.

Half-price calling with Goal: A 30-second US / CA domestic outbound call costs $0.1288 with One-shot-call or $0.0644 with Goal, excluding preparation usage. Choose Goal for batch and large-scale calling.

Billing guide: See Billing for the interactive cost breakdown and more examples. Preparation may incur model fees even without a connection; the experimental Task Success Fee remains fully waived.

All prices are in USD.

2026-09-23 — Calls & SDK 1.0

Calls and SDK 1.0: Single-target Calls are available through the production API and the TypeScript and Python 1.0.0 SDKs. Start with Quickstart or SDKs.

• Send one phone and task with a required result schema and idempotency key.
• Region and language hints are optional; ambiguous or conflicting input returns actionable validation errors instead of silently changing the target.
• Read call_outcome, result_status and a fixed transcript array on Calls and Goal Runs. A final unavailable result may have both result and error null.
• Use call_id to match the telephone call to Billing; keep id for API requests.
• Read detailed lifecycle, ASR and speech events, or receive a finalized webhook.
• Calls execute immediately. Cancellation is available only before submission.

Upgrade note: SDK 1.0 changes the Calls input and response shapes. Old SDK Goal Run wait helpers can time out on final unavailable results. Upgrade those helpers or poll REST using result_status. See Migration. Legacy call tasks remain available during migration and are planned for retirement at the end of 2026. See Retirement.

API versions and migration:

The current OpenAPI snapshot describes the released Calls and Goal Runs contracts. Its info.version is distinct from:

• the URL prefixes used by Calls, Goal Runs and legacy call tasks;
• openapi: 3.1.0, the format of the schema document;
• the installed SDK package version;
• run_spec.version, the published workflow version pinned by a Goal Run.

Current guides target SDK 1.0.0; legacy examples retain SDK 0.7.x. Updating an SDK does not select a historical server contract. Keep the contract snapshot and package lockfile used to validate your integration; compare request and response schemas when upgrading. The linked historical snapshots below are references, not endpoints for executing old versions.

Legacy Calls: correct an older recipient example:

An example using a singular recipient object should be corrected to recipients[].phones[]. This is an example correction, not a documented API version transition: the published 0.2.0 contract already used recipients. Do not infer that the singular form was supported.

The explicit-recipient part of a legacy call-task request is:

Code
{
  "recipients": [{ "phones": ["<E164_PHONE>"] }]
}

This is a field excerpt, not a complete create request: task is required. A recipient's region and locale are optional; check supported destinations before supplying them. Use the complete Python or Ruby example for creation, durable request storage, and result retrieval. The Python command pins SDK 0.7.0; Ruby uses HTTP directly without an SDK.

Legacy REST and Python use result_schema and return structured_result. TypeScript uses resultSchema and returns structuredResult. These are SDK naming conventions, not different server API versions. Keep property names inside user-defined schemas unchanged.

Goal Runs: phone-only requests in 0.6:

The July 22 release replaced the preview target wrapper and per-Run voice settings with a top-level phone and variables. The published 0.6.0 contract and the current Goal Runs contract use this shape:

Code
{
  "phone": "<E164_PHONE>",
  "variables": { "customer_name": "Taylor" }
}

Earlier preview input	Current input
Phone inside target	Top-level phone
Per-Run region / locale	Configure the published Goal's voice settings
Per-Run display_name	A variable such as customer_name, only if defined by the Goal's input schema

Read the published input schema before choosing variable names. Remove the old fields rather than sending both shapes. Preserve the request and idempotency key for an uncertain accepted Run; do not change its payload as part of a retry. Follow the Goal Runs flow for the required headers, creation, and polling.

Goal Runs: nullable call ID in 0.7:

Contract 0.7.0 added call_id to Goal Run responses. For a queued Run, the response-field change is:

Code
 {
   "id": "rgrp_delivery_ord_8472",
   "run_id": "run_delivery_ord_8472",
+  "call_id": null,
   "status": "queued"
 }

This excerpt omits unchanged fields. Update strict response validators to accept call_id as a string or null (callId in TypeScript). It is available for correlation when persisted; it does not prove a call was answered. Keep using the Goal Run's top-level id in the Goal Run polling URL and stop polling when result or error is non-null. The create request remains phone plus variables; it does not accept call_id.

2026-09-19 — Editable Prompts

Editable prompt modules: Customize Facts, Opening, Callee Identity Check, Identity Disclosure, First Sentence Upon Reaching Live Human, and Conversation Flow by editing their corresponding sections in the runtime LLM's system prompt.

Clearer credit top-ups: The top-up flow now shows how many credits you receive for the selected dollar amount, making the conversion clear before purchase.

Developer resource links: Added direct links to the documentation and product website from the Dashboard's developer page.

Dashboard calling reliability: Improved the Dashboard calling workflow following reports of intermittent call delivery. The reported issue has not been reproduced after recent optimizations, and monitoring continues (#121).

2026-09-14 — Billing & Concurrency

Updated concurrent call limits: The shared number pool supports 1 simultaneous call, purchased numbers support 10 simultaneous calls, and SIP integrations have no CALL-E-imposed concurrent call limit. These limits refer to calls active at the same time, not call initiation rate (calls per second, or CPS).

Updated billing model: Calls are now billed in 10-second increments, with total cost consisting of a Call fee and a Success fee. The Call fee covers actual carrier charges and model resource usage, including a small preparation and pre-connection model cost even when a call is not connected.

The Success fee applies only when the task's defined business success criteria are met. A connected call, an answered call, or a completed conversation alone does not qualify as success. For example, a reservation task succeeds only when the requested booking is confirmed—not simply when someone answers or discusses availability. Call fees may still apply when those success criteria are not met.

2026-09-10

Windows-compatible agent commands: Updated agent integrations now run correctly in PowerShell and Command Prompt, fixing failures caused by Unix-only command syntax (#111).

Reliable CLI selection: Agent integrations now verify and launch the correct CALL-E CLI, preventing command conflicts when the Developer API SDK is also installed (#109).

Multiline call goals on Windows: The updated agent launcher preserves multiline goals, Unicode text, and quoted arguments without shell parsing errors (#159).

Structured MCP results: Call planning, execution, and status tools now return structured results directly, so MCP integrations can access their fields without parsing JSON from text blocks (#158).

2026-09-07 — Number Verification

Clearer call failure reporting: Improved call failure details and corrected cases where platform or connection failures were reported as recipient declines (#206, #82, #111, #195).

Developer API calls in Call Records: Calls created through the Developer API now appear in Dashboard Call Records and can be found using their provider call ID (#151).

KYC for purchased numbers: Identity verification (KYC) is now required before purchased numbers can make outbound calls, strengthening security and compliance. The shared number pool is intended only for development and testing; for production, use your own purchased numbers with completed KYC or connect through a SIP integration.

2026-09-03 — Server SDK 0.7

Server SDK 0.7.0: The stable TypeScript and Python packages now include the Calls and Goal Runs client surfaces. Goal Run responses expose the nullable call_id field for call correlation when that persisted identifier is available. The TypeScript SDK source is available under the MIT License at CALLE-AI/server-sdk-typescript.

2026-08-28 — Goal Call Analysis

CLI supported regions discovery: The CALL-E CLI now includes calle regions list for reviewing supported country, region, and language combinations—including call direction, availability, configuration values, and additional setup requirements—before running plan_call.

Goal call analysis: The Dashboard can now analyze Call Records associated with a Goal and provide recommendations for improving future calls.

2026-08-21

Safer calle call start result handling: CALL-E CLI and @call-e/core now recognize JSON results returned through MCP content blocks while preserving the original response. This prevents valid run_call results from being treated as missing a run_id, helping users avoid unsafe retries when a call may already have started.

Longer call-planning timeout: Call planning now uses a dedicated 150-second timeout, reducing failures caused by the previous 15-second default. An explicit --timeout-seconds value continues to override the planning timeout (#79).

Reliable Goal publishing: Fixed an issue that could leave a Goal in Draft while the Dashboard reported that publication was proceeding (#135).

Correct call activity timelines: Fixed cases where ringing or calling events could appear after a call had already ended (#112).

Reliable Goal Run authorization: Fixed an authorization issue that could cause an accepted Goal Run to fail before the outbound call started (#106).

2026-08-15 — Dashboard Upgrade

Clearer call plan CLI guidance: The CLI documentation now points users to calle call plan --help to view the parameters supported by the call plan subcommand.

More informative MCP timeout errors: Timeout failures for MCP tools/call requests now include additional error information to make them easier to diagnose.

Phone keypad IVR support: CALL-E now supports phone keypad IVR interactions.

Dashboard Call Records: The Dashboard now includes Call Records for reviewing task history, conversations, and call audio recordings.

SDK and API integration examples: The Dashboard now includes SDK and API integration examples and can display the instruction associated with each Goal.

Durable multi-session execution: Users can run tasks concurrently across different chat sessions while each session keeps one active task at a time. Accepted tasks continue through page refreshes, closed tabs, and temporary connection or service interruptions.

Session recovery and clearer task status: The Dashboard restores messages, progress, drafts, user-facing reasoning summaries, and final Goal results after reconnecting. Clearer task states remain synchronized across current and background sessions.

Reliable commands and call control: Messages, interaction answers, reauthorization, and Stop requests can be retried without creating duplicate work. Stop applies only to its intended task, while uncertain call submissions are verified before retrying.

Dashboard reliability fixes: Fixed issues that could lose or stall accepted tasks, duplicate messages or calls, mislabel queued work, or leave the Dashboard out of sync. Stop outcomes now reflect confirmed results and preserve a task's true completion state.

2026-08-11 — Dashboard API Keys

Dashboard-issued API keys: Developer API authentication now accepts the iams_live_ API keys shown in the CALL-E dashboard. The server SDK configuration remains unchanged: pass the key through CALLE_API_KEY, and the SDK sends it as a Bearer credential.

2026-07-29 — Terminal Webhooks

Terminal webhook delivery: Call tasks that include webhook_url now send terminal event notifications to that URL. Each notification includes a stable event id for idempotent processing, and delivery is retried when the receiver does not return a 2xx response. CALL-E waits until the post-call outcome and requested structured results are finalized, so the webhook contains the same complete terminal snapshot returned by the Calls API.

Current deliveries include CALL-E-Event-Id for deduplication and do not include a webhook secret, timestamp, or signature header. Receivers must treat the payload as untrusted input, validate the event shape, and compare the header event id with the body id. The Python and TypeScript SDKs keep their legacy signed-webhook helpers only for source compatibility and mark them deprecated.

2026-07-22 — Simplified Goal Runs

Phone-only Goal Run requests in API 0.6: Create Goal Run requests now use a top-level phone plus variables. The target wrapper and per-Run region, locale, and display_name fields have been removed. Voice region and callee locale are fixed by the published Goal; recipient names needed by the conversation belong in the Goal's input schema and are supplied through variables.

The TypeScript and Python SDK source candidates now implement the matching client.goals surface at version 0.6.0, including Goal discovery, Run creation, Run reads, and result-or-error polling. Existing Calls and Webhooks surfaces remain compatible; registry packages stay on their current stable versions until the 0.6.0 release is published.

Simplified Goal Runs API 0.5: This release includes:

1. Useful Goal metadata: Goal list and get responses now include the current published title and description alongside the input and result schemas.

2. Smaller response: Goal and Goal Run responses expose RunSpec ids and versions without content fingerprints.

3. One result contract: a Goal Run returns the parsed object directly in result, or one unified error when execution or result processing fails. When both are null, clients continue polling.

4. Goal discovery: GET /v1/goals lists the authenticated owner's active, listed, published Goal interfaces with opaque cursor pagination. The API 0.5 SDK design adds client.goals.list(...) in both TypeScript and Python while keeping stable 0.2 packages Calls-only until a matching SDK minor is released.

2026-07-21 — Goal Runs Preview

Goal Runs API preview: This preview includes:

1. Published Goal interface: Read the current normalized input schema, result schema, and RunSpec identity with GET /v1/goals/{goal_id}.

2. Goal Run creation: Create one singleton Run with POST /v1/goals/{goal_id}/runs. Requests supply one target, scalar variables, and a required business-stable Idempotency-Key; they cannot replace the published schemas or choose a RunSpec version. Initial acceptance and exact replay both return 201.

3. Result polling: Read execution and schema-bound results with GET /v1/goals/{goal_id}/runs/{goal_run_id}. The Goal Run preserves the exact RunSpec version pinned when CALL-E accepted it.

4. SDK transition: The Goal Runs guide defines TypeScript and Python parity on client.goals, with get, run, get-Run, wait, and run-and-wait helpers using each language's naming convention. Stable 0.2 SDK packages continue to support the one-shot Calls API until matching next-minor packages are released.

See Goal Runs for request, polling, version-pinning, and SDK examples.

2026-06-08 — Developer API & SDKs

Developer API and server SDKs: This release includes:

1. Developer API: Create outbound call tasks, retrieve call task details, list call task events, and receive terminal webhook messages from a trusted server environment.

2. TypeScript server SDK: The CALL-E TypeScript server SDK is available on npm.

Terminal
pnpm add @call-e/calle

Use CalleClient to create a call task and wait for a terminal result.

3. Python server SDK: The CALL-E Python server SDK is available on PyPI.

Terminal
pip install calle-ai

Import CalleClient from calle to create call tasks and poll results.

4. Server-side integrations: API keys and server SDKs are designed for trusted backend services, workers, and automation systems. Browser SDKs, scheduled call tasks, cancel call task APIs, and project-level webhook management are not part of this release.