10-digit phone numbers must be registered with carriers through a multi-step process: 1. **Brand Registration** — register Warren's business with The Campaign Registry (TCR). Requires: legal business name, EIN (tax ID), business address, stock ticker (if public), and vertical classification. 2. **Campaign Registration** — register each use case (transactional notifications and promotional marketing are separate campaigns). Requires: campaign description, sample messages, opt-in flow description, and message volume estimate. 3. **Carrier Approval** — each carrier (T-Mobile, AT&T, Verizon) approves the campaign individually. Approval takes 1-5 business days. Some campaigns are rejected and must be resubmitted with modifications. Mark cannot complete A2P registration through the API alone. Brand registration requires Warren's EIN and legal business details. Campaign registration requires human-written descriptions of the use case that comply with carrier guidelines. Carrier approval is a manual review process. Until registration completes, Warren's account has a throughput limit of approximately **1 message per second** per phone number and messages may be filtered or blocked by carriers. Mark's 340-message campaign will take at least 6 minutes to send at 1 msg/sec — if none are filtered. Mark files the A2P registration through Twilio's Trust Hub API: ```bash POST https://trusthub.twilio.com/v1/CustomerProfiles Content-Type: application/json { "friendly_name": "Warren's Logistics Platform", "email": "warren@trackfast.io", "policy_sid": "RN806dd6cd175f314e1f96a121b9122a5b" } ``` The registration requires additional document uploads, identity verification, and business validation. Mark can initiate the process but cannot complete it without Warren providing the EIN, a business utility bill, and descriptive text for each campaign. The regulatory compliance layer is fundamentally human-centric. ## TwiML: XML for Voice Warren also needs voice capabilities — an IVR system where delivery drivers call in to confirm drop-offs. Mark sets up an incoming call handler. Twilio does not use JSON for voice call flows. It uses **TwiML** — Twilio Markup Language, an XML-based domain-specific language: ```xml Welcome to TrackFast delivery confirmation. Press 1 to confirm delivery. Press 2 to report an issue. We did not receive your input. Goodbye. ``` TwiML must be served from a publicly accessible URL. When a call comes in, Twilio sends an HTTP request to the `voice_url` configured on the phone number, and the URL must return TwiML XML. Mark needs to host an endpoint that generates TwiML dynamically based on the caller and the delivery context. The `` element collects DTMF input. The `action` attribute points to another URL that receives the keypress and returns more TwiML. A simple IVR with three menu levels requires three URL endpoints, each generating XML, each handling state passed through query parameters. Mark is writing an XML-based state machine spread across multiple HTTP endpoints. Voice calls and SMS are separate API surfaces in Twilio. A phone number has a `voice_url` and an `sms_url` — two different webhook endpoints for two different protocols. The message format for SMS is form-encoded key-value pairs (`From`, `To`, `Body`). The message format for voice is TwiML XML. Mark is operating two different APIs on the same phone number. ## The Multi-Tenant Sub-Account Problem Warren's platform serves multiple merchants. Each merchant's customers should receive SMS from a number associated with that merchant. Twilio's recommended approach for multi-tenant applications is **sub-accounts** — each merchant gets a sub-account with its own phone numbers, messaging services, and billing. ```bash POST https://api.twilio.com/2010-04-01/Accounts.json Authorization: Basic base