Monitoring and results
Consumption sits outside the numbered route. Everything on this page works from the first completed call onward and stays available for the life of the integration. It has a page of its own because the audience usually differs: your analytics or CRM people, rather than the engineers who did phase 2.
Two directions
Section titled “Two directions”- You pull. Your system polls or queries for outcomes, history and recordings. Nothing new to operate on your side.
- Voicebot pushes. Each finished call goes to the webhook targets configured on the agent that ran it. Voicebot persists a delivery before attempting it, so you can inspect and replay a failed one.
The outcome of one call. Each accepted call produces exactly one outcome.
GET/v1/communication/{id}Everything that happened during it. The step-by-step execution history: which bricks ran, what was recognised, where the call branched.
GET/v1/communication/{id}/historyAudio. The call recording, and the speech-recognition recordings the history points at.
GET/v1/communication/{id}/recordingGET/v1/communication/{id}/speech-recording
Bulk. List with filters, sorting and paging for reporting jobs.
GET/v1/communicationYou configure the targets on the agent, through PATCH/v1/agent/{id}. The operations below act on the deliveries once they exist.
GET/v1/communication-resultGET/v1/communication-result/{id}
POST/v1/communication-result/{id}/resend
Reading a status correctly
Section titled “Reading a status correctly”Lifecycle status and call outcome are two independent axes. Both carry a failed value, and
the two meanings differ, so a report that sums them counts two unrelated events as one. The
glossary defines both axes.