Twilio API Product Overview
Twilio's Core Value Proposition: Abstract the complexity of global telecommunications infrastructure behind simple, RESTful APIs that developers can integrate in minutes.
API Product Lines
| Product |
Purpose |
Traffic Pattern |
Latency Sensitivity |
| Programmable Messaging |
SMS, MMS, WhatsApp, RCS |
Async (store-and-forward) |
Low (seconds OK) |
| Programmable Voice |
PSTN calls, SIP, WebRTC |
Real-time (connection-based) |
Critical (<150ms) |
| Programmable Video |
Video rooms, recordings |
Real-time (streaming) |
Critical (<150ms) |
| Twilio Verify |
OTP, 2FA, fraud prevention |
Sync request-response |
Medium (<500ms) |
| Lookup |
Phone number intelligence |
Sync request-response |
Medium (<500ms) |
| Flex |
Contact center platform |
Mixed (real-time + async) |
High (<200ms) |
| Segment |
Customer data platform |
Async (event streaming) |
Low (eventual OK) |
| SendGrid |
Email delivery |
Async (batch) |
Low (minutes OK) |
Architecture Tiers
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ GLOBAL TIER │
│ Services that must be available everywhere, low latency from any location │
│ │
│ • API Gateway / Cell Router (Lambda@Edge) │
│ • Identity & Authentication (DynamoDB Global Tables) │
│ • Customer → Cell Routing (DynamoDB Global Tables + Redis) │
│ • DNS (Route 53 with latency-based routing) │
│ • CDN (CloudFront for static assets, TwiML bins) │
└─────────────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ REGIONAL TIER │
│ Services deployed per region, may have primary/secondary │
│ │
│ • Super Network (carrier connections in each region) │
│ • Media Servers (voice/video processing) │
│ • Message Queues (Kafka, regional clusters) │
│ • Lookup/Intelligence Services │
└─────────────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ CELL TIER │
│ Customer-specific isolation, product-agnostic cells │
│ │
│ • Message Processing (per-customer) │
│ • Call State Management │
│ • Customer Data Storage (Aurora, DynamoDB) │
│ • Webhook Delivery │
│ • Usage Metering │
└─────────────────────────────────────────────────────────────────────────────────────┘
Twilio API Conventions
Base URL Structure
https://api.twilio.com/2010-04-01/Accounts/{AccountSid}/Messages.json
Components:
├── api.twilio.com → Base domain
├── 2010-04-01 → API version (date-based)
├── Accounts/{AccountSid} → Account scoping
├── Messages → Resource (plural noun)
└── .json → Response format
Authentication
# HTTP Basic Auth with Account SID and Auth Token
curl -X POST https://api.twilio.com/2010-04-01/Accounts/AC.../Messages.json \
-u "ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:your_auth_token"
# Alternative: API Keys (Account SID + API Key SID + API Key Secret)
curl -X POST https://api.twilio.com/2010-04-01/Accounts/AC.../Messages.json \
-u "SKXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:your_api_key_secret"
# API Keys provide:
# - Granular permissions (can be scoped)
# - Revocable without changing Auth Token
# - Multiple keys per account
Resource Identifiers (SIDs)
| Prefix |
Resource Type |
Example |
AC |
Account |
ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
SM |
SMS Message |
SMXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
MM |
MMS Message |
MMXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
CA |
Call |
CAXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
PN |
Phone Number |
PNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
RE |
Recording |
REXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
SK |
API Key |
SKXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
VE |
Verify Service |
VAXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
Interview Insight: SID prefixes enable quick identification of resource types in logs, debugging, and support. A 34-character SID with 2-char prefix leaves 32 chars of uniqueness—likely a UUID variant.
Request/Response Format
# Request: Form-encoded (traditional) or JSON
POST /2010-04-01/Accounts/AC.../Messages.json
Content-Type: application/x-www-form-urlencoded
To=+15551234567&From=+15559876543&Body=Hello%20World
# Response: JSON (note PascalCase for legacy API)
{
"sid": "SM1234567890abcdef1234567890abcdef",
"account_sid": "AC1234567890abcdef1234567890abcdef",
"to": "+15551234567",
"from": "+15559876543",
"body": "Hello World",
"status": "queued",
"direction": "outbound-api",
"date_created": "Wed, 15 Jan 2024 10:30:00 +0000",
"date_updated": "Wed, 15 Jan 2024 10:30:00 +0000",
"date_sent": null,
"uri": "/2010-04-01/Accounts/AC.../Messages/SM....json",
"price": null,
"price_unit": "USD"
}
Pagination
# Request with pagination
GET /2010-04-01/Accounts/AC.../Messages.json?PageSize=50
# Response includes navigation URIs
{
"messages": [...],
"first_page_uri": "/2010-04-01/Accounts/AC.../Messages.json?PageSize=50",
"next_page_uri": "/2010-04-01/Accounts/AC.../Messages.json?PageSize=50&PageToken=PA123",
"previous_page_uri": null,
"page": 0,
"page_size": 50
}
# Note: Twilio uses keyset/cursor pagination (PageToken), not offset
# This is important for large datasets that change frequently
Webhook Pattern
# When creating a message, specify callback URL
POST /2010-04-01/Accounts/AC.../Messages.json
To=+15551234567
From=+15559876543
Body=Hello
StatusCallback=https://your-app.com/webhooks/message-status
# Twilio POSTs status updates to your webhook
POST https://your-app.com/webhooks/message-status
Content-Type: application/x-www-form-urlencoded
MessageSid=SM123...
MessageStatus=delivered
To=+15551234567
From=+15559876543
AccountSid=AC123...
# Your server must respond 2xx to acknowledge
# Twilio retries on failure (exponential backoff)
Programmable Messaging APIs
Traffic Pattern: Asynchronous, store-and-forward. Messages are queued, processed, and delivered with status callbacks. Latency tolerance is high (seconds to minutes acceptable).
API Endpoints
Messages Resource ASYNC
# Create (send) a message
POST /2010-04-01/Accounts/{AccountSid}/Messages.json
# Get message details
GET /2010-04-01/Accounts/{AccountSid}/Messages/{Sid}.json
# List messages
GET /2010-04-01/Accounts/{AccountSid}/Messages.json
# Update message (redact, cancel)
POST /2010-04-01/Accounts/{AccountSid}/Messages/{Sid}.json
# Delete message
DELETE /2010-04-01/Accounts/{AccountSid}/Messages/{Sid}.json
Messaging Services ASYNC
Higher-level abstraction that manages sender selection, compliance, and scaling.
# Create messaging service
POST /v1/Services
# Add phone numbers to service
POST /v1/Services/{ServiceSid}/PhoneNumbers
# Send via service (auto-selects best sender)
POST /v1/Services/{ServiceSid}/Messages
Message Lifecycle & Status
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ accepted │───►│ queued │───►│ sending │───►│ sent │───►│delivered │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
│ │ │ │ │
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ failed │ │ canceled │ │ failed │ │undelivered│ │ read │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
(WhatsApp)
Each transition triggers StatusCallback webhook if configured
Backend Infrastructure (Inferred)
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ MESSAGING ARCHITECTURE │
│ │
│ ┌─────────┐ ┌──────────────┐ ┌──────────────┐ ┌─────────────────────┐ │
│ │ API │────►│ Cell Router │────►│ Customer │────►│ Message Queue │ │
│ │ Gateway │ │ (by account) │ │ Cell │ │ (Kafka/SQS) │ │
│ └─────────┘ └──────────────┘ └──────────────┘ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────┐ │
│ │ SUPER NETWORK (Global) │ │
│ │ │ │
│ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │
│ │ │ US Carriers│ │ EU Carriers│ │APAC Carriers│ │LATAM Carriers│ │ │
│ │ │ AT&T, T-Mo │ │Vodafone,O2 │ │ Singtel... │ │ Claro... │ │ │
│ │ └────────────┘ └────────────┘ └────────────┘ └────────────┘ │ │
│ │ │ │
│ │ 4,800+ carrier connections | SMPP/SMPP over TLS | Intelligent routing │ │
│ └─────────────────────────────────────────────────────────────────────────────┘ │
│ │
│ Infrastructure Characteristics: │
│ • Cells: Product-agnostic, customer-isolated │
│ • Queue: Per-cell Kafka topics for message processing │
│ • Super Network: SHARED global infrastructure (not per-cell) │
│ • Delivery: Async with retry, DLQ for failures │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
Architecture Tags
Cell-Based
Regional Queue
Global Super Network
Cell Architecture Fit: Messaging is an excellent fit for cells. Each customer's messages are processed in their cell, providing isolation. The Super Network is shared globally—carrier connections are expensive and don't need per-customer isolation. Message queues can be regional Kafka topics partitioned by cell.
Programmable Voice APIs
Traffic Pattern: Real-time, connection-based. Voice requires sub-150ms latency for natural conversation. Media processing is regional; signaling can be more distributed.
API Endpoints
Calls Resource REAL-TIME
# Initiate outbound call
POST /2010-04-01/Accounts/{AccountSid}/Calls.json
To=+15551234567
From=+15559876543
Url=https://your-app.com/twiml/answer # TwiML instructions
# Get call details
GET /2010-04-01/Accounts/{AccountSid}/Calls/{Sid}.json
# Modify in-progress call
POST /2010-04-01/Accounts/{AccountSid}/Calls/{Sid}.json
Status=completed # Hang up
# List calls
GET /2010-04-01/Accounts/{AccountSid}/Calls.json
Recordings ASYNC
# List recordings for a call
GET /2010-04-01/Accounts/{AccountSid}/Calls/{CallSid}/Recordings.json
# Get recording audio
GET /2010-04-01/Accounts/{AccountSid}/Recordings/{Sid}.mp3
# Delete recording
DELETE /2010-04-01/Accounts/{AccountSid}/Recordings/{Sid}.json
Conferences REAL-TIME
# List conferences
GET /2010-04-01/Accounts/{AccountSid}/Conferences.json
# Get conference details
GET /2010-04-01/Accounts/{AccountSid}/Conferences/{Sid}.json
# List participants
GET /2010-04-01/Accounts/{AccountSid}/Conferences/{Sid}/Participants.json
# Kick participant
DELETE /2010-04-01/Accounts/{AccountSid}/Conferences/{Sid}/Participants/{CallSid}.json
TwiML (Twilio Markup Language)
<?xml version="1.0" encoding="UTF-8"?>
<Response>
<!-- Text-to-speech -->
<Say voice="Polly.Amy" language="en-GB">Welcome to Twilio!</Say>
<!-- Gather DTMF or speech input -->
<Gather input="dtmf speech" timeout="5" numDigits="1" action="/handle-input">
<Say>Press 1 for sales, 2 for support, or say your request.</Say>
</Gather>
<!-- Connect to another number -->
<Dial callerId="+15559876543" timeout="30">
<Number>+15551234567</Number>
</Dial>
<!-- Play audio file -->
<Play>https://example.com/hold-music.mp3</Play>
<!-- Record the call -->
<Record maxLength="300" transcribe="true" transcribeCallback="/transcription" />
<!-- Conference call -->
<Dial>
<Conference waitUrl="/hold-music" startConferenceOnEnter="true">
RoomName123
</Conference>
</Dial>
</Response>
Call Flow Architecture
┌──────────────────────────────────────────────────────────────────────────────────────┐
│ VOICE ARCHITECTURE │
│ │
│ INBOUND CALL: │
│ ┌────────┐ ┌─────────┐ ┌─────────────┐ ┌───────────┐ ┌───────────────┐ │
│ │ PSTN/ │───►│ Super │───►│ Regional │───►│ Customer │───►│ Customer │ │
│ │ Carrier│ │ Network │ │ SIP Gateway │ │ Cell │ │ Webhook │ │
│ └────────┘ └─────────┘ └─────────────┘ └───────────┘ │ (TwiML fetch) │ │
│ │ └───────┬───────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────┐ ┌───────────────┐ │
│ │ Media Server│◄───────────────────│ TwiML Parser │ │
│ │ (Regional) │ Instructions │ & Executor │ │
│ │ │ └───────────────┘ │
│ │ - RTP/SRTP │ │
│ │ - Mixing │ │
│ │ - Recording │ │
│ │ - TTS/STT │ │
│ └─────────────┘ │
│ │
│ OUTBOUND CALL: │
│ ┌───────────┐ ┌───────────┐ ┌─────────────┐ ┌─────────┐ ┌────────┐ │
│ │ API Call │───►│ Customer │───►│ Regional │───►│ Super │───►│ PSTN/ │ │
│ │ POST/Calls│ │ Cell │ │ SIP Gateway │ │ Network │ │ Carrier│ │
│ └───────────┘ └───────────┘ └─────────────┘ └─────────┘ └────────┘ │
│ │
│ Key Components: │
│ • Super Network: PSTN interconnects (regional, near carriers) │
│ • Media Servers: Audio processing (MUST be regional for latency) │
│ • SIP Gateways: Protocol translation (regional) │
│ • Call State: Cell-local (ephemeral during call) │
│ • Recordings: S3 (regional, replicated to customer's region) │
│ │
└──────────────────────────────────────────────────────────────────────────────────────┘
Architecture Tags
Regional Media
Cell Signaling
Global Routing
Cell Architecture Considerations: Voice is tricky for cells. Call signaling (setup, teardown, TwiML) can be cell-based, but media processing MUST be regional for latency. A US-to-UK call might have signaling in the customer's US cell but media servers in both US and UK regions. Call state is ephemeral—stored in the cell during the call, then persisted to the database after completion.
Programmable Video APIs
Traffic Pattern: Real-time streaming. Even more latency-sensitive than voice due to visual synchronization needs. WebRTC-based with SFU (Selective Forwarding Unit) architecture.
API Endpoints
Rooms REAL-TIME
# Create a room
POST /v1/Rooms
UniqueName=DailyStandup
Type=group # or peer-to-peer, group-small
# Get room details
GET /v1/Rooms/{Sid}
# Complete a room (end the meeting)
POST /v1/Rooms/{Sid}
Status=completed
# List participants in room
GET /v1/Rooms/{RoomSid}/Participants
Recordings & Compositions ASYNC
# List recordings
GET /v1/Rooms/{RoomSid}/Recordings
# Create composition (combine recordings)
POST /v1/Compositions
RoomSid=RM123...
AudioSources=*
VideoLayout={"grid":{"video_sources":["*"]}}
# Get composition status
GET /v1/Compositions/{Sid}
Room Types & Architecture
| Room Type |
Max Participants |
Architecture |
Use Case |
| Peer-to-Peer (P2P) |
~4 |
Direct WebRTC between clients |
1:1 calls, small meetings |
| Group Small |
~6 |
SFU with optimization |
Small team meetings |
| Group |
50 |
SFU (Selective Forwarding) |
Large meetings, webinars |
┌──────────────────────────────────────────────────────────────────────────────────────┐
│ VIDEO ROOM ARCHITECTURE (SFU) │
│ │
│ ┌─────────────────────────┐ │
│ │ SFU Media Server │ │
│ │ (Regional) │ │
│ │ │ │
│ ┌──────────┐ │ ┌─────────────────┐ │ ┌──────────┐ │
│ │ Client A │◄────────┼──┤ Receive tracks │ │─────────►│ Client B │ │
│ │ (sends │ │ │ from all others │ │ │ (receives│ │
│ │ video) │────────►│ └─────────────────┘ │◄─────────│ all) │ │
│ └──────────┘ │ │ └──────────┘ │
│ │ ┌─────────────────┐ │ │
│ │ │ Forward to each │ │ │
│ ┌──────────┐ │ │ subscriber │ │ ┌──────────┐ │
│ │ Client C │◄────────┼──┤ (no transcoding)│ │─────────►│ Client D │ │
│ └──────────┘ │ └─────────────────┘ │ └──────────┘ │
│ │ │ │
│ └─────────────────────────┘ │
│ │
│ SFU Benefits: │
│ • Each client uploads once (to SFU) │
│ • SFU forwards to all subscribers │
│ • No transcoding = lower latency │
│ • Bandwidth efficient for many participants │
│ │
│ Regional Deployment: │
│ • SFU servers in each region (us-east, eu-west, ap-southeast) │
│ • Participants connect to nearest SFU │
│ • SFUs interconnect for cross-region rooms │
│ │
└──────────────────────────────────────────────────────────────────────────────────────┘
Architecture Tags
Regional SFU
Edge Signaling
Cell for Room State
Cell Architecture Considerations: Video room metadata (who's in the room, permissions) can be cell-based. But the actual media flows through regional SFU servers—these must be as close to participants as possible. A global company might have a meeting with participants in US, EU, and APAC—each connects to their regional SFU, and the SFUs mesh together. Recordings are processed regionally and stored in the customer's designated region for compliance.
Verify & Lookup APIs
Verify API
Purpose: User verification via OTP codes sent over SMS, Voice, Email, WhatsApp, or TOTP. Critical for fraud prevention and 2FA.
Verification Flow SYNC
# Step 1: Create verification service (one-time setup)
POST /v2/Services
FriendlyName=MyAppVerification
CodeLength=6
# Step 2: Start verification (sends code)
POST /v2/Services/{ServiceSid}/Verifications
To=+15551234567
Channel=sms # or voice, email, whatsapp
Response: { "status": "pending", "sid": "VE123...", "to": "+15551234567" }
# Step 3: Check code (user submits code)
POST /v2/Services/{ServiceSid}/VerificationCheck
To=+15551234567
Code=123456
Response: { "status": "approved", "valid": true }
# or: { "status": "pending", "valid": false } if wrong code
Lookup API
Phone Number Intelligence SYNC
# Basic lookup (formatting, carrier)
GET /v2/PhoneNumbers/+15551234567
Response:
{
"phone_number": "+15551234567",
"national_format": "(555) 123-4567",
"country_code": "US",
"carrier": {
"name": "Verizon",
"type": "mobile",
"mobile_country_code": "311",
"mobile_network_code": "480"
}
}
# Advanced lookup with add-ons
GET /v2/PhoneNumbers/+15551234567?Fields=line_type_intelligence,caller_name
Response includes:
"line_type_intelligence": { "type": "mobile" },
"caller_name": { "caller_name": "John Doe", "caller_type": "CONSUMER" }
Backend Architecture
┌──────────────────────────────────────────────────────────────────────────────────────┐
│ VERIFY & LOOKUP ARCHITECTURE │
│ │
│ VERIFY FLOW: │
│ ┌──────────┐ ┌──────────┐ ┌───────────────┐ ┌───────────────────────────┐ │
│ │ API Call │───►│ Customer │───►│ Verify Service│───►│ Channel Delivery │ │
│ │ │ │ Cell │ │ (rate limit, │ │ • SMS: Messaging Pipeline │ │
│ │ │ │ │ │ fraud check) │ │ • Voice: Voice Pipeline │ │
│ └──────────┘ └──────────┘ └───────────────┘ │ • Email: SendGrid │ │
│ │ └───────────────────────────┘ │
│ ▼ │
│ ┌───────────────┐ │
│ │ Code Storage │ │
│ │ (Redis/Dynamo)│ │
│ │ TTL: 10 min │ │
│ └───────────────┘ │
│ │
│ LOOKUP FLOW: │
│ ┌──────────┐ ┌──────────┐ ┌───────────────┐ ┌───────────────────────────┐ │
│ │ API Call │───►│ Customer │───►│ Lookup Service│───►│ Data Sources │ │
│ │ │ │ Cell │ │ (cache first) │ │ • Internal carrier DB │ │
│ │ │ │ │ │ │ │ • Third-party providers │ │
│ └──────────┘ └──────────┘ └───────────────┘ │ • Number portability DB │ │
│ │ └───────────────────────────┘ │
│ ▼ │
│ ┌───────────────┐ │
│ │ Response Cache│ │
│ │ (Redis) │ │
│ │ TTL: 24 hours │ │
│ └───────────────┘ │
│ │
│ Key Characteristics: │
│ • Verify: Stateful (codes stored), fraud detection, rate limiting │
│ • Lookup: Stateless, heavily cached, third-party data aggregation │
│ • Both are GLOBAL services but can route through customer cells │
│ │
└──────────────────────────────────────────────────────────────────────────────────────┘
Architecture Tags
Cell API Layer
Global Verify Service
Regional Cache
Cell Architecture Fit: Verify and Lookup APIs route through customer cells for billing and rate limiting, but the actual verification logic and phone number databases are global services. Verification codes are stored in a fast, global cache (DynamoDB Global Tables or Redis) because users might verify from a different region than they requested the code.
Twilio Flex APIs
Purpose: Programmable contact center platform. Flex is a React-based frontend with APIs for task routing, agent management, and omnichannel communication.
Core Concepts
| Concept |
Description |
API |
| Workspace |
Container for contact center config |
TaskRouter API |
| Task |
Unit of work (call, chat, email) |
TaskRouter API |
| Worker |
Agent who handles tasks |
TaskRouter API |
| Workflow |
Rules for routing tasks to workers |
TaskRouter API |
| Channel |
Communication type (voice, SMS, chat) |
Conversations API |
TaskRouter API SYNC
# Create a task (customer contacts you)
POST /v1/Workspaces/{WorkspaceSid}/Tasks
Attributes={"type":"support","priority":1,"customer_id":"C123"}
WorkflowSid=WW123...
# Accept a reservation (agent picks up)
POST /v1/Workspaces/{WorkspaceSid}/Tasks/{TaskSid}/Reservations/{ReservationSid}
ReservationStatus=accepted
# Complete a task
POST /v1/Workspaces/{WorkspaceSid}/Tasks/{TaskSid}
AssignmentStatus=completed
Conversations API ASYNC
# Create conversation (omnichannel thread)
POST /v1/Conversations
FriendlyName=Support-Case-123
# Add participant (customer via SMS)
POST /v1/Conversations/{ConversationSid}/Participants
MessagingBinding.Address=+15551234567
MessagingBinding.ProxyAddress=+15559876543
# Add participant (agent via Flex UI)
POST /v1/Conversations/{ConversationSid}/Participants
Identity=agent@company.com
# Send message
POST /v1/Conversations/{ConversationSid}/Messages
Author=agent@company.com
Body=How can I help you today?
Flex Architecture
┌──────────────────────────────────────────────────────────────────────────────────────┐
│ FLEX ARCHITECTURE │
│ │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ FLEX UI (React) │ │
│ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ │
│ │ │ Agent │ │ Task List │ │ Customer │ │ CRM Panel │ │ Custom │ │ │
│ │ │ Desktop │ │ │ │ Info │ │ │ │ Plugins │ │ │
│ │ └───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘ │ │
│ └──────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ FLEX BACKEND │ │
│ │ │ │
│ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │
│ │ │ TaskRouter │ │ Conversations │ │ Flex Insights │ │ │
│ │ │ (Routing) │ │ (Omnichannel) │ │ (Analytics) │ │ │
│ │ └────────┬────────┘ └────────┬────────┘ └─────────────────┘ │ │
│ │ │ │ │ │
│ │ ▼ ▼ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ Underlying Channels │ │ │
│ │ │ Voice │ SMS │ WhatsApp │ Chat │ Email │ │ │
│ │ │ (Each uses respective Twilio API) │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
│ │
│ Cell Architecture: │
│ • Each Flex customer (contact center) can be a cell │
│ • TaskRouter state is customer-specific │
│ • Conversations span channels but are customer-isolated │
│ • Analytics aggregated per customer │
│ │
└──────────────────────────────────────────────────────────────────────────────────────┘
Architecture Tags
Cell per Contact Center
Regional TaskRouter
Global Config
Segment CDP APIs
Purpose: Customer Data Platform. Collects events from all sources, unifies customer profiles, and activates data to 700+ destinations.
Core Concepts
| Concept |
Description |
| Source |
Where data comes from (website, mobile app, server) |
| Destination |
Where data goes (analytics, marketing, data warehouse) |
| Track |
Event call (user did something) |
| Identify |
User call (who the user is) |
| Profile |
Unified customer record from all sources |
Tracking API ASYNC
# Track an event
POST https://api.segment.io/v1/track
{
"userId": "user_123",
"event": "Order Completed",
"properties": {
"orderId": "ORD-456",
"total": 99.99,
"currency": "USD",
"products": [
{ "sku": "SKU-1", "name": "Widget", "price": 49.99 }
]
},
"timestamp": "2024-01-15T10:30:00Z"
}
# Identify a user
POST https://api.segment.io/v1/identify
{
"userId": "user_123",
"traits": {
"email": "john@example.com",
"name": "John Doe",
"plan": "enterprise",
"company": {
"name": "Acme Inc",
"industry": "Technology"
}
}
}
Segment Architecture (Inferred)
┌──────────────────────────────────────────────────────────────────────────────────────┐
│ SEGMENT CDP ARCHITECTURE │
│ │
│ INGESTION LAYER: │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Web SDK │ │ Mobile │ │ Server │ │ Cloud │ │
│ │ (JS) │ │ SDKs │ │ Libraries│ │ Sources │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │ │
│ └─────────────┴─────────────┴─────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ TRACKING API (Edge/Global) │ │
│ │ Low latency, high throughput │ │
│ └──────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ KAFKA BACKBONE │ │
│ │ • Ingest topic: Raw events │ │
│ │ • Processed topic: Enriched, validated events │ │
│ │ • Per-destination topics: Filtered events │ │
│ └──────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────┼────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌─────────────┐ ┌──────────────┐ │
│ │ RocksDB │ │ Centrifuge │ │ Destination │ │
│ │ (Dedup) │ │ (MySQL-as- │ │ Connectors │ │
│ │ │ │ queue) │ │ (700+) │ │
│ │ 60B keys │ │ │ │ │ │
│ │ per node │ │ Guaranteed │ │ Google Ads │ │
│ │ │ │ delivery │ │ Salesforce │ │
│ │ Prevents │ │ │ │ Snowflake │ │
│ │ duplicate│ │ │ │ etc. │ │
│ │ events │ │ │ │ │ │
│ └──────────┘ └─────────────┘ └──────────────┘ │
│ │
│ PROFILE STORE: │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ Unified Customer Profiles (DynamoDB or custom store) │ │
│ │ • Identity resolution across sources │ │
│ │ • Computed traits │ │
│ │ • Audience membership │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────────────────────────┘
Architecture Tags
Edge Ingestion
Regional Kafka
Cell per Workspace
Cell Architecture Fit: Each Segment workspace (customer) can be a cell. Event streams are partitioned by workspace. The Tracking API is global/edge for latency, but downstream processing happens in customer-specific Kafka partitions. RocksDB deduplication is per-workspace. Destinations are workspace-specific. Profile data has strong customer isolation requirements (GDPR).
SendGrid Email APIs
Purpose: Transactional and marketing email delivery at scale. Focus on deliverability, ISP reputation management, and analytics.
Mail Send API ASYNC
# Send email (v3 API)
POST https://api.sendgrid.com/v3/mail/send
{
"personalizations": [
{
"to": [{"email": "john@example.com", "name": "John Doe"}],
"subject": "Welcome to Our Service"
}
],
"from": {"email": "noreply@company.com", "name": "Company"},
"content": [
{"type": "text/plain", "value": "Welcome!"},
{"type": "text/html", "value": "Welcome!
"}
],
"tracking_settings": {
"click_tracking": {"enable": true},
"open_tracking": {"enable": true}
}
}
SendGrid Architecture
┌──────────────────────────────────────────────────────────────────────────────────────┐
│ SENDGRID ARCHITECTURE │
│ │
│ ┌──────────┐ ┌───────────────┐ ┌───────────────┐ ┌───────────────────────┐│
│ │ API Call │───►│ Ingestion │───►│ Message Queue │───►│ MTA Cluster ││
│ │ │ │ (validation, │ │ (prioritized) │ │ (Mail Transfer Agent) ││
│ └──────────┘ │ rate limit) │ │ │ │ ││
│ └───────────────┘ └───────────────┘ │ - IP warming ││
│ │ - ISP throttling ││
│ │ - Feedback loops ││
│ └───────────┬───────────┘│
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────┐│
│ │ DESTINATION ISPs ││
│ │ Gmail │ Outlook │ Yahoo │ Others ││
│ │ ││
│ │ • Reputation management per IP ││
│ │ • Bounce/complaint processing ││
│ │ • Feedback loop handling ││
│ └─────────────────────────────────────┘│
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐│
│ │ EVENT WEBHOOKS ││
│ │ delivered │ opened │ clicked │ bounced │ spam_report │ unsubscribed ││
│ │ ││
│ │ POST to customer webhook with event details ││
│ └─────────────────────────────────────────────────────────────────────────────────┘│
│ │
│ Key Characteristics: │
│ • IP Reputation: Shared vs Dedicated IP pools │
│ • ISP Throttling: Different rates for Gmail vs others │
│ • Bounce Handling: Hard vs soft bounce logic │
│ • Suppression Lists: Global unsubscribes, bounces │
│ │
└──────────────────────────────────────────────────────────────────────────────────────┘
Architecture Tags
Cell per Account
Regional MTA
Global Suppression
Infrastructure Patterns Summary
Service-to-Infrastructure Mapping
| Service |
Cell Scope |
Regional Components |
Global Components |
| Messaging |
Customer messages, webhooks |
Kafka, message processing |
Super Network (carriers) |
| Voice |
Call state, TwiML handling |
Media servers, SIP gateways |
PSTN routing, DID inventory |
| Video |
Room metadata, permissions |
SFU media servers |
Room routing, signaling |
| Verify |
Rate limits, billing |
Code cache |
Fraud detection, templates |
| Lookup |
Rate limits, billing |
Response cache |
Carrier databases |
| Flex |
TaskRouter, agents |
Real-time events |
Configuration |
| Segment |
Workspace data, profiles |
Kafka, destinations |
Schema registry |
| SendGrid |
Customer mail |
MTA clusters |
Suppression lists |
Cell Architecture Decision Framework
When to put in a Cell:
- Customer-specific data (messages, calls, events)
- Customer-specific processing (webhooks, routing logic)
- Data that needs isolation (compliance, blast radius)
- State that scales with customer usage
When to keep Regional:
- Latency-sensitive media processing (voice, video)
- Carrier connections (can't duplicate for each customer)
- Message queues (regional Kafka clusters)
- Caching layers
When to keep Global:
- Identity and authentication
- Customer → cell routing tables
- Shared infrastructure (carrier contracts, IP pools)
- Configuration that rarely changes
API Gateway Pattern
┌──────────────────────────────────────────────────────────────────────────────────────┐
│ API REQUEST FLOW │
│ │
│ Customer Request │
│ POST /2010-04-01/Accounts/AC123.../Messages.json │
│ Authorization: Basic {AccountSid:AuthToken} │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────┐ │
│ │ 1. EDGE (CloudFront / Global Accelerator) │ │
│ │ • TLS termination │ │
│ │ • DDoS protection │ │
│ │ • Geographic routing │ │
│ └────────────────────────────────────────────────────────────────┬────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────┐ │
│ │ 2. API GATEWAY (Lambda@Edge or Regional API Gateway) │ │
│ │ • Authentication (validate AccountSid:AuthToken) │ │
│ │ • Rate limiting (token bucket per account) │ │
│ │ • Request validation │ │
│ │ • API versioning (extract 2010-04-01 from path) │ │
│ └────────────────────────────────────────────────────────────────┬────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────┐ │
│ │ 3. CELL ROUTER │ │
│ │ • Lookup: AccountSid → CellId (Redis cache, DynamoDB fallback) │ │
│ │ • Route to correct cell (VPC Lattice by service name) │ │
│ │ • Add headers: X-Twilio-Cell-Id, X-Twilio-Account-Id │ │
│ └────────────────────────────────────────────────────────────────┬────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────┐ │
│ │ 4. CUSTOMER CELL │ │
│ │ • Version-specific handler (transform request/response) │ │
│ │ • Business logic (create message, queue for delivery) │ │
│ │ • Customer database (Aurora in cell) │ │
│ │ • Webhook dispatch (to customer's StatusCallback URL) │ │
│ │ • Usage metering (async to billing) │ │
│ └─────────────────────────────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────────────────────────┘
Interview Talking Points
API Design Insights
- Date-based versioning allows long-term stability
- Account scoping enables multi-tenancy at URL level
- SID prefixes aid debugging across systems
- Webhook pattern for async status updates
- TwiML provides domain-specific abstraction
Architecture Insights
- Cell-based for customer isolation and blast radius
- Regional for latency-sensitive media
- Global for shared infrastructure (carriers, identity)
- Super Network is key differentiator (can't replicate)
- Async patterns enable scale (store-and-forward)
Key Takeaways
Your Narrative: "Twilio's APIs are the product—they abstract telecommunications complexity behind REST endpoints. The architecture supports this with cell-based isolation for customer data, regional deployment for latency-sensitive media, and global infrastructure for shared carrier connections. Each API product has different characteristics: Messaging is async and tolerates latency; Voice and Video are real-time and require regional media servers; Verify needs global code storage for cross-region verification. Understanding these patterns helps me design APIs that scale while maintaining the developer experience that makes Twilio successful."
Quick Reference
| Product |
Pattern |
Cell Fit |
Key Infrastructure |
| Messaging |
Async, store-forward |
Excellent |
Kafka, Super Network |
| Voice |
Real-time, connection |
Signaling only |
Media servers (regional) |
| Video |
Real-time, streaming |
Metadata only |
SFU servers (regional) |
| Verify |
Sync request-response |
Rate limiting |
Global code cache |
| Segment |
Async, event streaming |
Excellent |
Kafka, RocksDB |
| SendGrid |
Async, batch |
Good |
MTA clusters, IP pools |