Webhooks allow HubTalk AI v4 to send call data to your systems automatically after the call ends. Use them to power dashboards, CRM updates, or business automations.
Every webhook endpoint names an agent, and that agent must be a live agent of your organization. There is no organization-wide endpoint: a subscription without an agent name is refused with webhooks.agent_required, and an agent that is unknown or archived is refused with webhooks.agent_not_found.
There is no organization-wide subscription. If your integration needs events for several agents, register the endpoint once per agent. A row with an empty agent name, if one sits in the database, is inert: it is not deleted, and it receives nothing.
To receive the same events for several agents, add the endpoint to each of them. The same URL may be reused: the payload carries agent_id, so one receiver can still handle them all.
An agent’s webhooks live in the 🪝 Webhooks (post-call) section of the settings panel in the builder. Add webhook opens a form with these fields:
Endpoint URL — the HTTPS address that receives the notifications. http:// is available only to the platform owner organization.
Events — what to send:
Call ended (call_ended) — after the call finishes;
Analytics ready (call_analyzed) — when post-call analytics is ready.
Signing secret — env variable name — only the reference is stored: the value is read from the environment and never hits the database or the logs.
Response timeout (sec) — the maximum wait for your endpoint’s response; 0 uses the pipeline default.
Enabled — delivery can be paused without deleting the address.
Send test-session events — off by default, so dashboard tests do not fire the webhook.
The form has no agent field of its own: the webhook belongs to the agent whose settings you created it in. A saved endpoint carries a Test button in the list, which sends a trial notification without waiting for a real call.
After configuration, use a test call or webhook inspector to confirm that the payload arrives at your endpoint and the data format matches your expectations.
HubTalk AI v4 can send a second webhook once post-call analytics finish processing. The call_analyzed event contains the complete call object plus the analysis results, so a subscriber only needs this one event to get the full picture — subscribing to call_ended as well is optional.
Both events carry an error_code field — the numeric failure code assigned by the telecom operator (for example 486 with status_reason = busy). It is null when the operator reported no code. Operators interpret these codes differently — do not build strict logic on them without checking with your own operator. Note as well that busy and user_declined are distinct reasons: a busy line and a subscriber hanging up are told apart.If analysis was skipped or failed, call_analysis is empty and a reason field explains why, for example voicemail or no_speech. When the call has a recording, call_analyzed also includes a top-level recording_url and a recording object once the recording is ready — call_ended carries the same recording block, but it is often still processing at that point.
A call that never connected — no answer, busy, a failure, an answering machine — still produces a webhook, and that webhook carries dynamic_variables: the values you supplied for the contact when the call was queued. Nothing was collected during the conversation, because there was no conversation, but the input of the call is there.
Do not use an empty dynamic_variables as a no-answer signal. The variables arrive both on a connected call and on an unanswered one, so an empty dictionary says nothing about the outcome. Branch on call_status and status_reason instead — those are the fields that state it.
Three surfaces show the same thing: the call variable inside post-call functions, the dictionary in the call-ended webhook, and GET /v1/calls/{call_id} in the Web API — for one call the data agrees.
