CALL-E provides server SDKs for trusted backend services, workers, and automation systems that create and monitor call tasks.
Packages
TypeScript package name:
Code
@call-e/calle
Python distribution name:
Code
calle-ai
Python imports the package as calle:
Code
from calle import CalleClient
Package status
The current stable server SDK packages are:
TypeScript: @call-e/calle@0.2.2
Python: calle-ai==0.2.0
These stable packages support the request-scoped Calls API. The Goal Runs
API and both SDK source candidates are aligned on 0.6.0; the registry
packages remain Calls-only until that matching SDK release is published.
Goal Runs preview
The Goal-based SDK surface keeps published contracts separate from the
one-shot Calls API:
TypeScript: client.goals.list(...), get(...), run(...), getRun(...),
waitForResult(...), and runAndWait(...)
Python: client.goals.list(...), get(...), run(...), get_run(...),
wait_for_result(...), and run_and_wait(...)
Run requests contain Goal identity, one phone number, per-Run variables, and an
idempotency key. They do not accept request-scoped task text, prompts,
input_schema, or result_schema; those fields are owned by the published
RunSpec. See the Goal Runs guide for the API contract and SDK
examples.
Source repositories
The SDKs are maintained as separate repositories so they can have independent release cadence, CI, package metadata, and language-specific examples.
Each SDK repository currently includes runnable examples for the server-side
one-shot call task flow.
TypeScript:
Code
git clone https://github.com/CALLE-AI/server-sdk-typescript.gitcd server-sdk-typescriptpnpm installpnpm run example:create-and-waitpnpm run example:webhook
Python:
Code
git clone https://github.com/CALLE-AI/server-sdk-python.gitcd server-sdk-pythonuv sync --all-groupsuv run python examples/create_and_wait.pyuv run python examples/webhook_server.py
The webhook examples listen on POST /calle/webhook and verify CALL-E-Timestamp plus CALL-E-Signature before parsing JSON.
Stable 0.2 methods
The SDKs expose context as a reserved input for future SDK-side workflow data. The current SDKs do not send context to the API.
Examples use phone placeholders such as <E164_PHONE> and <RECIPIENT_1_E164_PHONE>. Replace them with phone numbers you own or are authorized to call.
The SDKs accept structured result schemas as plain JSON objects. Use field description values to explain how CALL-E should interpret enum values, and use type, required, enum, and additionalProperties for hard validation. See the Calls guide for structured result design patterns and examples.