Call Data API Overview

Voicetta answers the phone. This API hands you the result.

Every completed voice call becomes a single structured object: who called, what was said, what the caller wanted, what happened, how long it took, and a link to the audio. You decide what to do with it — show it in your own dashboard, file it against a customer record, trigger a workflow, or bill on it.

What you can build

The shape of the data is deliberately close to what a call-review screen needs, because that is the most common thing people build with it.

• A white-label call dashboard. Voicetta runs the voice agent; your product is what your client logs into. They never see our branding.
• A CRM or PMS timeline. Attach the transcript and outcome to the record for the person who called.
• Workflow automation. Route on analysis.outcome or analysis.intent — escalate the unhappy calls, auto-close the resolved ones.
• Quality reporting. Evaluation verdicts and latency measurements per call, aggregated however you like.

Push, pull, or both

There are two ways to get the same call object, and most integrations end up using both.

Start with the webhook: it is the path that keeps your data current without polling. Add the read API when you need history from before you integrated, or to recover deliveries your server missed while it was down.

The payload is the same either way, so one handler function covers both.

The base URL

Every read API request goes here, authenticated with a bearer token. The webhook goes the other direction: to a URL you own.

Getting access

1. In the Voicetta dashboard, open Settings → Developers.
2. Create an API key for reading, or a webhook endpoint for receiving. You can have both.
3. Choose which blocks of call data each one may use — field groups for the webhook control what we push; field groups on the API key control what it may pull.
4. Ask us to enable delivery for your workspace.

Both API keys and webhook signing secrets are shown once, at creation, and stored only as a hash. If you lose one, rotate it rather than asking us to retrieve it — we cannot.

When the data arrives

The call.completed event fires when post-call processing finishes, not when the caller hangs up. That is a deliberate few-seconds delay: by the time you receive the event, the transcript, summary, evaluations, and recording are final.

You never have to poll for a field that has not been filled in yet, and you never have to reconcile a partial call with a later, more complete version of the same call.

What "version 1" promises

The payload carries "version": 1, and every read API path starts with /v1.

Within version 1 we will only add fields. We will not rename a field, remove one, change a type, or change the meaning of an existing value. Anything that would break a working integration gets a new version number and a new X-Voicetta-Payload-Version, and version 1 keeps working.

Two consequences worth designing for:

• Ignore fields you do not recognise. A new field appearing is normal and is not a reason to reject a payload.
• Do not treat a missing key as an error. Null values are omitted rather than sent as null, so a key you saw yesterday may be absent today simply because that call had no value for it.

Reading these docs as an LLM

Every page here has a Markdown twin, served as plain text:

• This page: /developers/overview.md
• All developer pages as one file: /developers.md
• The OpenAPI 3.1 spec for the read API: /open-api

The spec is generated from the running API rather than written by hand, so it cannot drift from what the endpoints actually accept and return. Point a code generator at it, or paste /developers.md into a coding agent and let it write the handler.

Related pages

• Quickstart — a working delivery in about ten minutes
• Webhook reference — the full payload, headers, and signature verification
• Read API reference — endpoints, parameters, pagination, and errors
• n8n and no-code — receiving calls without writing a server