Skip to main content
Browser calling uses a scoped, single-use token instead of a general-purpose calling credential. This page is precise about what each path guarantees, so you can match it to your risk tolerance. There are two tiers of enforcement:
  • Every path issues scoped, short-lived, single-use tokens, validates the caller ID against numbers you own, attributes every call, and bounds the blast radius with account guardrails.
  • The server-originated paths (join + bridge) additionally lock the destination by construction: the client never dials, so the call can’t be redirected or replayed.

​
How a token is issued and bounded (all paths)

The token you receive is an opaque RevDesk token (rvw_…), not a reusable calling credential. It is issued for one call, tied to a caller ID you own, and recorded for attribution.
On the browser-direct path the destination is declared, attributed, and guardrail-bounded, but the browser is what dials, so the destination is not locked by construction. For a hard destination lock, use a server-originated path (below).

​
Canceling abandoned browser setup

Keep the call_id returned by POST /v1/webrtc-token. If browser setup fails, your server can send POST /v1/calls/{id}/hangup?mode=setup_failed. When the user cancels before dialing, use mode=cancel_setup. These requests require calls:write and no request body; a browser-only voice:webrtc client token cannot call this endpoint. Never expose your server API key to the browser. Both setup modes act only on unused, queued browser tickets. They revoke the ticket and mark it CANCELED, with the setup diagnostic recorded separately and no verified talk time. A browser error or missing webhook does not prove the handset failed to ring. They do not interrupt an originated call, even if origination races with cancellation. Repeating the request on a terminal call returns its current status. Omit mode (or use mode=hangup) to end an actual call as usual. An unused ticket also receives a five-minute server-side cleanup deadline. This is an abandonment timeout, not an active-call duration limit: originated calls retain their normal credential lifetime. Failed setup is not a completed conversation, readiness evidence, or a spam-label observation. Retry explicitly with a new ticket; the system does not redial automatically. Call lifecycle and recipient outcome are separate. A finished attempt can have status: "completed" and call_outcome: "screened" when the recipient explicitly reported screening it (disconnection_reason: "call_screened"). This does not establish a human conversation: picked_up is false, and unknown timings stay null. Abandoned browser setup uses call_outcome: "connection_unconfirmed", not an inferred carrier failure or spam label.

​
Hard destination lock: server-originated paths

On the join and bridge paths, RevDesk’s server places the call and the client only joins it. The destination is fixed server-side, so it cannot be changed by the client and the token cannot be replayed to reach a different number.

​
Bridge: caller-ID masking

When a person connects on their own phone (bridge), the called party only ever sees your RevDesk number, never the person’s personal number.

​
Account guardrails (defense in depth, all paths)

These cap the blast radius even if a token were leaked:

​
Security questions, answered

Yes. Every token is issued for one from_number → to_number, is single-use, and is valid only for that one call. It’s invalidated when the call ends (its lifetime covers the platform’s max call duration so it never cuts an active call). On the browser-direct path the destination is declared, attributed, and bounded by the account guardrails. For a destination that cannot be changed or replayed, use a server-originated path (join or bridge), where the client never dials.
Yes. from_number must be a number your organization owns; we validate ownership at issuance and only mint a token for a number you control.
A destination allowlist (blocks international/premium ranges), a daily spend limit, a concurrency cap, and a max per-minute rate, all enforced at the account level on every call, so a leaked token’s blast radius is bounded.
Every call is anchored to a record carrying your organization, the issuing user, and the from/to. Reconcile with GET /v1/calls.
No, by design. A number anyone can dial can’t authenticate the caller, lock the destination, or mask caller ID per call. The bridge path places both legs from the server instead: you call POST /v1/calls/dial, RevDesk rings your phone and the called party, then bridges them. That server-placed model is what makes per-call attribution and caller-ID masking possible. For a phone (cellular, no browser), bridge is the path; see Choosing a calling path.
It’s single-use (one call only) and guardrail-bounded. To make a token non-replayable for origination, usable only through a call RevDesk sets up, use a server-placed path (B or C): the client holds no dialing credential at all, only a grant to join a call RevDesk placed. See Choosing a calling path.