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).

​
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.