How to Set Up Two-Way SMS Messaging With Twilio, A2P Registration Included

Twilio's core appeal for an engineering team is exactly what makes it different from a packaged marketing SMS platform: raw, composable APIs with no visual campaign builder and no built-in compliance tooling, which means an engineering team can build precisely the messaging workflow a product needs, and also means every piece of infrastructure a packaged tool would have handled automatically, registration, opt-out handling, delivery monitoring, has to be built deliberately. Here's the setup that gets two-way SMS working without discovering a missing piece only once real messages start failing.

For background on what Twilio is, its actual per-message cost once carrier surcharges apply, and how it compares to a packaged SMS marketing platform, see our full Twilio profile.

Step 1: Complete A2P 10DLC Registration in the Correct Order

Before sending any real US SMS traffic, complete Application-to-Person 10-digit long code registration in the sequence it actually requires: create a Customer Profile in the Twilio Console first, then register a Brand under that profile (typically approved by The Campaign Registry within minutes), and only then register a Campaign describing the specific messaging use case. Skipping or reordering these steps, or attempting to send meaningful volume before registration completes, is one of the most common reasons US SMS traffic gets throttled or blocked entirely, and it's a carrier-level requirement Twilio itself can't bypass on a customer's behalf.

Step 2: Choose the Campaign Use Case Honestly, Not Whichever Approves Fastest

When registering the Campaign, select the use case category that actually matches what the messaging will do, two-factor authentication, customer care, marketing, mixed conversational, rather than whichever category seems likely to clear review fastest. A mismatched use case declared at registration doesn't just risk an initial rejection, it risks ongoing throttling or filtering once real traffic doesn't match the registered pattern, which is a more disruptive problem to discover after launch than a slightly longer initial approval process.

Step 3: Configure the Number or Messaging Service to Receive Inbound Messages

In the Twilio Console, set the phone number's (or Messaging Service's) inbound message webhook to point at a public endpoint your application controls, configured to receive an HTTP POST for every incoming message. This is what actually enables two-way messaging, without it, the number can send outbound messages but has no mechanism to deliver an inbound reply back into your application logic at all.

It's also worth deciding upfront whether inbound routing should live on an individual phone number or on a Messaging Service that groups multiple numbers together. A Messaging Service adds a layer of configuration that pays off once a system needs sender pooling, geographic number matching, or multiple numbers sharing one set of webhook and compliance settings, while a single number configured directly is simpler for a smaller, single-purpose integration that doesn't need that flexibility yet.

Step 4: Build the Reply Logic in Your Webhook Handler

In the application code handling that webhook, parse the incoming message payload and either respond immediately using TwiML in the webhook response itself, or trigger a follow-up message through Twilio's REST API for logic that needs more processing time before replying. Since Twilio provides no built-in conversation UI or bot logic, this handler is where the actual two-way conversation experience gets defined, whether that's a simple auto-reply, a multi-step conversational flow, or routing the message to a human agent elsewhere in the stack.

Step 5: Build Opt-Out Handling Yourself, Don't Assume It's Automatic

Unlike a packaged SMS marketing platform with compliance tooling built into every send, Twilio's own opt-out handling covers baseline carrier-level STOP compliance in the US, but the application layer still needs its own logic to check a suppression list before sending, and to update that list immediately when a STOP, HELP, or START keyword arrives through the inbound webhook. Treat this as application logic to build explicitly and test directly, rather than something to assume is fully handled just because the number is active on Twilio, since the consequences of a gap here are the same real compliance risk that applies to any SMS sending, packaged platform or not.

Step 6: Log Every Inbound and Outbound Message With Enough Context to Debug Later

Store a record of every message sent and received, including the raw payload, timestamps, and the specific webhook or API call that generated it, in your own application's data store rather than relying solely on Twilio's console history for troubleshooting. When a user reports a message they never received, or a reply that seemed to go nowhere, having your own searchable log tied to your application's user and conversation context resolves the question far faster than reconstructing the sequence from Twilio's console after the fact, especially once messaging volume is high enough that Twilio's own log retention or search isn't a practical first stop.

Step 7: Set Up Delivery Status Callbacks to Catch Failures

Configure a status callback webhook to receive delivery status updates, queued, sent, delivered, failed, undelivered, for every outbound message, and route failed or undelivered statuses into a monitoring process rather than only checking delivery manually when a user reports a problem. Since Twilio doesn't surface a built-in dashboard alert the way a packaged platform might, this callback is the only reliable, automatic way to know a message didn't land without waiting for the recipient to complain about not receiving it.

Step 8: Test the Full Send-and-Receive Loop Before Any Real User Sees It

Before connecting this to a real product flow, manually test the complete loop: send an outbound test message, confirm an inbound reply triggers the webhook correctly, confirm the application's reply logic fires as expected, and confirm a STOP keyword actually suppresses future sends to that number. Testing each piece in isolation can miss an integration gap between them, a webhook that's correctly configured in the console but pointing at the wrong endpoint in code, for instance, that only shows up once the full loop runs end to end.

A Few Mistakes That Undo This Setup

A handful of habits reliably undermine an otherwise correctly built Twilio integration. Registering the Campaign before the Brand has actually cleared review, or attempting to send meaningful volume while registration is still pending, produces exactly the throttling and filtering the registration process exists to prevent, and it's a self-inflicted delay that patience during the actual review window would have avoided. Building the reply logic and opt-out handling as an afterthought once the core send-and-receive path works, rather than as part of the initial build, means real users can interact with a system that technically works but doesn't yet honor a STOP request correctly, which is discovered at exactly the wrong time, after a real user has already been affected. And skipping the end-to-end test in Step 7 because each individual piece, the webhook, the reply logic, the opt-out check, tested fine in isolation, misses the integration failures that only surface when the full loop actually runs together.

What This Setup Actually Produces

Built this way, Twilio delivers exactly what makes it worth choosing over a packaged platform in the first place: a fully custom, two-way SMS experience with registration, reply logic, opt-out handling, and delivery monitoring all built deliberately rather than assumed. That's a meaningfully more reliable foundation than connecting a number, wiring up a basic send function, and discovering the gaps, a missing opt-out check, an unmonitored delivery failure, an incorrectly registered campaign use case, only once real users start interacting with it.

None of this requires a large engineering investment to get right the first time, it requires sequencing the work correctly: registration and compliance logic before volume, monitoring before scale, and a full end-to-end test before a real user is the one who discovers a gap.

If you're still deciding whether Twilio's developer-first approach fits your team versus a packaged SMS marketing platform, our Twilio tool profile covers the full cost and tradeoff breakdown in more detail.