What this is
Tuner needs one thing from your stack: the completed call — a structured conversation timeline plus metadata — sent once, after the call ends. Tuner then processes it and runs your configured analyses.Choose your path
The two paths produce identical results in Tuner and follow the same contract. Which one you take depends on your language, not your preference.Python SDKs
On a Python stack — start here. Attach observers to your STT, TTS, and LLM framework. They capture the transcript, per-turn timing, tool calls, usage, and cost for you, and send everything in one
flush() at call end.Direct API
Any other language. Build the call timeline yourself and POST it to the Create Call API after the call ends. More work — you assemble the per-turn timing and interruption data the SDKs derive automatically.
The contract
However you send calls, these identifiers decide which agent a call lands under:- workspace_id — the Tuner workspace receiving the call
- agent_remote_identifier — your Agent Remote ID, from Agent Settings → Agent Connection
- call_id — your unique identifier for the call; use the same value on every retry so ingestion stays idempotent
- sip_call_id (inbound simulation only) — the SIP
Call-IDfrom the inbound call, which links a simulated call back to its simulation run. See Simulation SIP setup. - recipient (outbound simulation only) — the SIP URI your system dialed, exactly as Tuner sent it. See Outbound Simulation.
Authentication
All API requests use Bearer authentication. Send your Tuner API key in theAuthorization header, copied from Workspace Settings → API Keys & Integrations:
TUNER_API_KEY environment variable and send it for you.
Webhooks
This agent can send events to a webhook — see Webhooks.Next steps
Python SDKs
The session lifecycle, observers, and one flush at call end.
Direct API
Build the payload yourself and POST it.
Create Call API reference
The full request/response schema both paths feed into.
Review your first call
What Tuner does with the data once it lands.