Define the schema, receive the values. Per-call token and cost accounting, extractions you can re-run against historical conversations, and workflow steps if you would rather not build the plumbing.
When post-call processing completes, an event carries the extracted payload to your endpoint: the conversation identifier, the agent, the extracted fields keyed by your own field names, the transcript, and a recording URL when one exists.
Because the field names come from your schema rather than ours, the payload shape is one you defined. Adding a field to the template adds a key; it does not reshape everything around it.
A separate event fires at the end of post-call analysis regardless of whether an extraction template was configured or whether extraction succeeded. That distinction matters when you are building a pipeline: one event means here is your data, the other means this call is finished being processed. Without the second, a consumer has no reliable signal for calls that produced nothing, and quietly stalls on them.
Fields are declared with a type — string, number, boolean, enum, date or array — and the response is parsed against those declarations. An enum constrains the model to the values you allow, which is the difference between a field you can switch on and one you have to normalise forever.
Dates deserve a specific mention. Every extraction is given a grounding block built from the calling agent's timezone, so a caller saying "next Tuesday" yields a real date computed from when the call actually happened rather than from your server's clock.
Extracted payload delivered when processing completes, plus a separate completion event that fires for every call regardless of outcome.
Field names come from your template. The payload does not change shape because we shipped something.
Input tokens, output tokens, processing time and cost recorded per extraction, not aggregated into a platform fee.
Apply a changed template to conversations that already happened instead of accepting a gap in the data.
Your own LLM key first if supplied, then the platform chain. A rate-limited provider degrades the run rather than dropping it.
CRM, Sheets, email, WhatsApp, SMS and generic HTTP steps, so simple destinations need no code at all.
The engine that runs post-extraction work advances one step at a time, and the schedule for retries and delays lives in the database rather than in a process's memory. A deploy, a restart or a crash does not strand work in progress — which is the failure mode most home-grown call pipelines discover about six weeks in, usually as a silent gap in a report.
Steps that fail are retried on that durable schedule, and executions that stop making progress are swept up against a configured timeout instead of sitting in a running state forever.
If you would rather extraction ran on your own LLM account, supply a workspace-level key. Requests served by your key are not billed by us. If the key fails for any reason — expired, rate-limited, revoked — the platform chain takes over so the extraction still completes, rather than the call producing nothing because of a credential problem on your side.
Workflows can be executed in a dry-run mode where control flow runs for real — conditions evaluate, variables are assigned, branches are chosen — while every outbound effect is simulated. You get the full trace of which path a given call took and what each step would have sent, without a webhook firing or a record changing.
There is also an ephemeral simulation that writes nothing at all and reports, per step, the resolved configuration, the variables produced, the complete variable bag afterwards, and any placeholders that failed to resolve. That last one catches the most common configuration error before it reaches production: a template referencing a field name that the extraction schema does not actually produce.
A completion event fires at the end of post-call analysis for every call, whether or not a template was configured and whether or not extraction succeeded. Consume that as your terminal signal and treat the extracted-data event as the payload when it arrives.
Yes. Retries are scheduled durably in the database rather than held in memory, so they survive restarts and deploys. Executions that stop progressing are swept against a timeout rather than remaining in a running state indefinitely.
Yes, per conversation. This is the normal way to handle a schema change: tighten a field description or add a field, then apply the new template to conversations that already exist.
Yes, at the workspace level. Extractions served by your key are not billed by us, and if that key fails the platform chain takes over so the extraction still completes.
Dry-run mode executes conditions and variable assignment for real while simulating every outbound effect, so you can confirm branching and payloads against real extracted data. A separate simulation writes nothing and reports unresolved placeholders per step.
No. Take the webhook payload and do whatever you like with it. The workflow steps exist so that common destinations — CRM, Sheets, messaging — do not require you to build and operate that plumbing yourself.
Define a schema, point a webhook at your endpoint, and inspect the payload from a real call.