Record Browser Call Answered
The browser telling us a call is up, so the call has a row to belong to.
⛔WITHOUT THIS A BROWSER-DIALLED CALL COULD NOT BE DISPOSITIONED AT ALL. Measured on ticket 60884, 2026-09-22: the agent finished a callback, opened the disposition prompt and got a red refusal naming a CallUUID that exists in no voice_calls row -- not as call_uuid, not as id. record_disposition was right to refuse; there was nothing to attach to.
⛔THE ROW WAS SUPPOSED TO COME FROM THE ANSWER URL AND FOR THIS DESK IT DOES NOT ARRIVE. /outbound/from-browser does write one -- but only if ticket_id is not None and call_uuid, so a dial carrying no ticket header writes nothing; and the route runs at all only while Plivo's BROWSER application points its answer URL at us, which that route's own docstring calls out as "a Plivo change, not a deploy". Its insert is also wrapped in a bare except Exception that logs and continues, because an agent is waiting on that XML. Three ways for the row to be missing, all of them silent, and the agent finds out at the one moment they cannot act.
So the fact is reported from the one place that always has it: the browser, which is holding the CallUUID because the SDK just handed it over on onCallAnswered. Same shape as /origination-failed above -- the softphone already tells us about the calls it could NOT place, and this is the other half of that sentence.
⛔NOT reconcile_the_call_uuid, AND THE PRECONDITION IS WHY. The bridge path reconciles because Plivo's REST API answers with a request_uuid and every later webhook carries a different CallUUID: the row is born wearing a placeholder and the real id arrives afterwards. A browser leg has no such split -- the SDK hands over the real CallUUID at once, and /outbound/from-browser already inserts with it -- so there is no placeholder to replace. Worse, reconciling here would be actively wrong: it keys on "the ONE unreconciled ringing row on this ticket", and browser rows satisfy call_uuid = request_uuid forever, so a NEW call would rewrite the identity of an OLDER stuck attempt. Ticket 60884 is carrying five rows still at 'ringing'; this conversation's disposition and recording would have landed on one of them.
⛔ALWAYS 200, AND THE BOOLEAN SAYS WHETHER IT LANDED. The agent is live on a call; a bookkeeping failure must never become something they see. recorded: false is for us, in the log beside it.
⛔EXCEPT A REFUSED DIAL, WHICH ANSWERS refused WITH THE SENTENCE (2026-09-24). That one IS for the agent: the dial they just pressed was stopped by the calling hours, and the softphone shows the same words the call leg spoke, instead of offering a disposition for a call that never reached anybody.
Request
- Base URL: https://api.pigeonly.com (the document declares no server; this is the origin it was published from)
- URL: https://api.pigeonly.com/api/voice/browser-call-answered
- Auth: none declared
Request body
Response
Successful Response
Changes
No recorded changes to this operation across all 1 revision of this API.