voice

Record Bridge Call Caller

The browser telling us who is on a cell-bridge call, the moment ring_them_back/outbound/cell-bridge hands back a call_uuid.

Frederick, 2026-09-25 (#2186): Cindy made a callback on the cell bridge and got no disposition screen, because that screen is wired to the softphone's own Plivo SDK and a bridge call never touches it -- Plivo rings the account manager's own phone, and the browser never learns the call started or ended. If the call ever goes undispositioned long enough to raise a Today card (bridge_disposition.raise_disposition_cards), this is how that card knows who to put it in front of instead of falling straight to the ticket's queue pool.

⛔SAME POSTURE AS record_browser_call_answered/record_origination_ failed just above: self-reported, best-effort, and ALWAYS 200. Nobody is on a live call waiting for this response the way they are for those two, but TicketDetailPage.ringBack fires it fire-and-forget right after a successful dial and must never be made to handle a failure here as if the callback itself had failed.

⛔ONLY ringBack FIRES THIS TODAY (Fable's review, F9, 2026-09-25 -- corrected the same day this route first shipped, which claimed the keypad's cell-bridge dial did too). SoftphonePanel.tsx's placeCellBridgeCall does not call it, so a keypad bridge dial placed FROM a ticket still gets a Today card if it goes undispositioned -- it just always falls to the ticket's queue pool rather than to a name. Left open (not silently wired) rather than claimed fixed.

post/api/voice/outbound/bridge-caller

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/outbound/bridge-caller
  • Auth: none declared

Request body

call_uuidstring required
ticket_idstring uuid nullable

Response

Successful Response

object required

Changes

No recorded changes to this operation across all 1 revision of this API.