Loading post…
TwilioLeroy ChanTutorial
On-Demand Masked Sessions with Twilio Proxy, Voice and Serverless
Summary
This tutorial presents a Just-in-Time (JIT) masked session workflow for securely connecting callers when phone numbers cannot be pre-associated because of inventory constraints. The design routes an inbound call to a reserved Twilio number through Twilio Voice, uses an IVR to collect a six-digit tracking code, and dynamically creates a private Twilio Proxy session. It uses five serverless endpoints plus helper functions; because the Out-of-Session Callback lacks keypad digits, a “2-Bounce” flow uses a redirect and a temporary Twilio Sync Document keyed by res- plus CallSid to carry the resolved destination, with a short TTL such as 900 seconds. On the second bounce, the destination is retrieved and deleted, and Proxy receives instructions to auto-create the session and bridge the caller. The result is an on-demand masked connection across standard cellular connections that avoids static phone-number preallocation and preserves the number pool.
Context
The workflow targets on-demand delivery, ridesharing, and marketplace services where customers, couriers, restaurants, drivers, or third-party contacts need masked communications but cannot always be associated with phone numbers in advance. A caller uses a reserved Proxy number and an order-specific tracking code to reach the other party.
Approach / What changed
The implementation uses Twilio Serverless Functions, Twilio Voice, Twilio Proxy, and Twilio Sync. An Out-of-Session Callback starts an IVR Gather, the Gather action performs a bidirectional lookup, and the resolved destination is stored temporarily in a Sync Document keyed by CallSid. A redirect triggers a second Proxy callback, which reads and deletes that resolution before returning instructions for automatic session creation. The tutorial also covers environment variables, deployment, Proxy configuration, testing, and signature validation for the callback that closes sessions.
Takeaways
The lookup maps a six-digit code to two parties, matches the caller against that pair, and returns the other party’s phone number, allowing the same code to support both directions.
Twilio Sync carries the resolved destination between callbacks because the second Out-of-Session Callback does not receive the DTMF digits; the temporary document uses res- plus CallSid and can have a 900-second TTL.
The session-closing callback validates the Twilio signature before logging or acting on the request, rejects invalid requests with 403, and acknowledges cleanup errors with 200 so Proxy does not retry.
FAQ
Why is a second bounce needed before the Proxy session can be created?
The first Out-of-Session Callback can collect the tracking code, but the callback does not contain the keypad digits. The Gather action stores the resolved destination in Twilio Sync and redirects the live call, allowing the second callback to retrieve the destination and instruct Proxy to create the session.
How does the lookup support calls in both directions?
Each tracking code maps to a pair of phone numbers. The lookup identifies which member of the pair is calling and returns the other number, so the same code can connect either party to the other.
How is the session-closing callback protected?
The callback validates the Twilio signature against the request parameters and callback URL before logging or closing a session. Requests without a valid signature receive a 403 response.
Source and freshness
- Source
- twilio.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.