Quick answer: A two-party proxy session gives a rider and a driver, a courier and a customer, or a buyer and a seller a single shared number to call or text — neither side ever learns the other's real phone number. On Devotel Orbit you create the session from Numbers → Masking in the dashboard: name the two participants, set how long the session lives, and every call or text either party places to the proxy number is relayed to the counterparty until the session closes or expires. Proxy numbers come from a pool you own, the session's expires_at is explicit, and closing a session releases the number back so a cancelled order does not keep a line reserved. This guide defines the primitive, walks the configuration, draws the line where masking meets the recording-consent boundary, covers the session lifecycle and expiry, states the consent/data-residency posture, and separates proxy masking from the UCaaS shared-lines family it is often confused with.
What a two-party proxy number is
A proxy session binds three numbers: your rider's real number, your driver's real number, and one number drawn from your proxy pool. When the driver calls the proxy number, Orbit rings the rider showing the proxy number as caller ID — and the same in reverse. Neither participant ever sees a real number, so when the trip ends there is no retained phone number on either side to misuse: no driver keeping a home number, no buyer reselling a customer's direct line.
This is the privacy primitive gig-economy, marketplace, and delivery platforms converge on for one reason: the two parties must be reachable for a bounded window, and nothing should be reachable after it. Masking answers "who can reach whom, and for how long" — it is not a consent gate. Whether you are allowed to contact the rider at all is decided by your own consent collection before the session is ever created; the masked session only hides identity while the contact it authorizes happens. The docs guide Choosing a privacy primitive puts masking alongside OTP, the WhatsApp 24-hour window, and RCS fallback with a decision tree; this post is the buyer-facing half.
Configuration under Numbers → Masking
The dashboard surface is the page at Numbers → Masking (shipped as the number-masking hub in the Orbit dashboard), which exposes the whole session lifecycle:
- Create a session. Name
participant_aandparticipant_bas E.164 numbers and set attl_minutesvalue — 1 to 1440 minutes, defaulting to 60 when omitted. The server assigns a proxy number from your pool and binds all three for the window. - Watch the session list. Sessions read back with status
active,closed, orexpired, each row carrying itsexpires_attimestamp so support staff can answer "why did the number stop working" without engineering. - Close early when the order ends. Closing a session is what returns the proxy number to the pool. If you let every completed delivery sit in the active state until expiry, the pool drains and new orders start failing assignments.
The same lifecycle is available over the API — POST /proxy/sessions to create, the list and detail GETs to poll, DELETE /proxy/sessions/:id to close — so the dashboard and the backend stay one surface. The walkthrough with webhook verification lives at Mask two parties' numbers with a proxy session.
Where the routing meets the recording-consent boundary
A masked session is a relay, and the moment you record that relay the consent question is yours to answer — the platform ships the controls, the tenant owns the policy. Two dashboards carry that boundary:
- Voice → Pause Reason Codes — when an agent or supervisor needs the recording paused mid-call (a card number being read out, a medically sensitive exchange), the reason catalog and the per-code max-seconds ceilings are administered there. The pause-reason-codes guide explains how agents attach the reason and how overrun alerts fire.
- Voice → Monitoring — the supervisor console where live masked calls are observed, whispered into, or barged, and where recording eligibility intersects with who is allowed to listen.
Underneath those consoles the legal layer is the one-party/all-party split our call-recording consent post maps in full: roughly forty US states permit one-party recording, eleven require all parties to consent, and the GDPR routes recording through lawful-basis and transparency duties that behave the same way. A masked call between a driver and a rider is not exempt from that map — the mask hides identity, it does not change the jurisdiction either party is standing in. On Orbit the tenant-set eligibility mode (which calls auto-record), the consent-announcement mode, and the recording policy are the three controls you configure; the reference is Call Recording Consent. One design note that matters for marketplaces specifically: if your policy announces recording, every participant needs the announcement — including the party who joined through a proxy number and never touched your IVR.
Per-session assignment and expiry
The assignment model is the part buyers underrate. A proxy session is not a permanent alias; it is a deliberately short-lived binding:
- Assignment is per session, not per user. The same rider gets a different proxy number on the Tuesday trip and the Thursday trip. There is no stable mapping an outsider can harvest.
- `ttl_minutes` is the whole lifecycle. Set it to the longest plausible completion window for the order type — a 45-minute ride plus buffer, a two-hour delivery window — not to a week. Sessions past
expires_atread asexpiredand no longer relay. - Close beats expire. An explicit close on order completion returns the number immediately; expiry is the safety net for the workflows that never send the completion signal.
- Pool size follows peak concurrent sessions, not registered users. A delivery platform doing 40,000 deliveries a day but never more than 1,200 in flight needs a pool in the low thousands, not tens of thousands — provided sessions close at fulfillment instead of relying on TTL.
Consent and data-residency notes
Masking changes what personal data exists at all, which is the strongest data-residency argument for it. A call log that carries a proxy number and two session-scoped bindings is a different retention subject than one storing every customer's direct line against your drivers' numbers. Three practical postures follow:
- The real numbers still exist in the binding record. Masking removes the numbers from user-visible surfaces (caller ID, SMS threads, driver apps), not from your platform's session store. Treat the session detail as personal data with the same retention discipline as the order it belongs to — close it, expire it, and purge on the schedule your privacy notice states.
- Recordings of masked calls inherit the residency posture of your voice tier. If your voice plan pins media to a region, the masked relay's recording lives there too; the masking layer does not relocate it. Pair masking with the residency posture in GDPR Data Residency for Voice and SMS when procurement asks where relay audio lands.
- Consent to contact is upstream of the mask. A proxy session is not evidence of consent to be contacted — it is the mechanism contact goes through after your own opt-in flow approved it. Tenant-owned controls only: Orbit exposes suppression, quiet-hours, and consent-capture gates; which of them your policy enforces is your call.
Where this differs from shared lines
Buyers migrating from a PBX vocabulary mix two primitives that solve different problems. Shared lines — and the rest of the UCaaS operations family (covered in the UCaaS operations guide) — distribute one known number across your own staff: a receptionist line ringing five phones, call park, ring groups, hot-desking. Everyone on a shared line is internal, the number is meant to be known, and the binding is permanent. Proxy masking does the opposite: it connects two external parties who must not learn each other's numbers, through a number that is deliberately disposable and expires with the transaction. If the parties are your employees, you want shared lines; if the parties are a customer and a contractor whose relationship ends at drop-off, you want a masked session. The two compose naturally — the courier's inbound support line can be a shared line while the customer-facing contact runs masked — but configuring one where the audit trail expects the other is how privacy programs end up with a permanent alias where they promised an ephemeral one.
Frequently asked questions
Does the rider need the Orbit app? No. A proxy session is a carrier-level relay — both parties use their native dialer and SMS client, and neither side installs anything.
Can a session carry SMS as well as voice? Yes. The same proxy number relays texts and calls for the session's lifetime, so a "I'm outside" text and a follow-up call take the same masked path.
What happens when the TTL runs out mid-conversation? The session flips to expired and stops relaying — the right answer is to size ttl_minutes to the order's realistic outer window and close explicitly at completion, not to fight expiry from the customer side.
Can the same proxy number serve two sessions at once? It serves one binding while assigned. Overlapping sessions each draw from the pool, which is why pool sizing tracks peak concurrency rather than total users.