Sending a text from code takes about ten minutes on any provider. The hard part of two-way SMS is everything after it: getting replies into your app, honoring STOP before the next send goes out, holding messages during quiet hours, and keeping carriers from filtering your traffic because the number was never registered for 10DLC.

This post compares four ways to build two-way texting: AWS End User Messaging, Twilio, a gateway you run yourself, and the Ready API. We make Ready, so we'll say plainly where the others win, including on raw per-segment price, where Twilio is lower. The real question is how much of the compliance and reply plumbing you want to own.

What "two-way" actually requires

Before comparing vendors, here is the work any two-way setup has to cover:

  1. A registered sending number. US application-to-person traffic on local numbers needs a 10DLC brand and campaign. Unregistered traffic gets carrier-filtered.
  2. Inbound routing. A reply has to reach your system as an event: a webhook, a queue message or a row you can poll.
  3. Opt-out handling. STOP, UNSUBSCRIBE and their variants have to suppress the contact everywhere, not just in one campaign.
  4. Conversation state. You need to match a reply to the right customer, the right thread and the right number it was sent from.
  5. Send-time rules. Quiet hours based on the recipient's area, consent records, and ideally a litigator and DNC screen.
  6. Segment-aware billing. Replies cost money too, and an emoji in an outbound message can triple its segment count.

Every option below handles some of this list. None of them handles all of it in a way that removes your legal responsibility as the sender.

AWS End User Messaging

AWS End User Messaging (the SMS side of what used to be Amazon Pinpoint) is a solid choice if your stack already lives in AWS and you're comfortable wiring services together.

How two-way works

You request an origination identity (a 10DLC number, toll-free number or short code), turn on two-way messaging for it, and point inbound messages at a destination. Usually that's an SNS topic, which you then fan out to Lambda, SQS or your own endpoint. Replies arrive as events you parse and store yourself.

Setup and compliance burden

  • New accounts typically start in a sandbox. You verify destination numbers and request production access and spend limits before you can text real customers.
  • You register the 10DLC brand and campaign through the AWS console or API. If you're a platform texting on behalf of your own customers, you build that per-tenant registration flow yourself.
  • AWS offers opt-out lists and keyword handling, but storing conversation threads, mapping replies to tenants and enforcing quiet hours is your code.

Cost

The underlying carrier cost is similar to the other providers. You pay AWS's per-message rate plus carrier fees, and the infrastructure around it (SNS, Lambda, a database for threads) is usually small but not zero. Check AWS's current pricing page for the exact numbers.

Good fit: AWS-native teams sending mostly notifications, with an engineer who owns the messaging pipeline.

Twilio

Twilio is the default for good reason. The docs are excellent, the SDKs cover every language, and the per-segment rate is low, at around $0.0083 per segment plus carrier fees.

How two-way works

You set a webhook URL on a number or Messaging Service. When a reply arrives, Twilio sends an HTTP request to your endpoint and you respond (optionally with TwiML) or process it on its own. This is the cleanest inbound model of the raw CPaaS options.

Setup and compliance burden

  • A2P 10DLC registration runs through Twilio's Trust Hub. It works, but for a multi-tenant platform you're building a registration flow for each customer, handling rejections, and tracking which numbers sit on which campaign. Our 10DLC registration API post walks through what that flow involves.
  • Advanced Opt-Out handles standard STOP keywords at the Messaging Service level. Cross-tenant suppression logic, quiet hours and a conversation inbox are yours to build.
  • Subaccounts give you billing separation, but registration and compliance are still per-subaccount work.

Cost

Twilio's per-segment rate is lower than ours, and if you have engineers who will build and maintain the compliance layer, that difference adds up at volume. That's a legitimate reason to pick Twilio.

Good fit: teams with messaging engineering capacity who want maximum control and the lowest per-segment rate.

Running your own gateway

"Gateway" covers two very different things, and only one of them is reasonable.

Self-hosted SMPP gateway

Open source software like Jasmin connects over SMPP to an aggregator you contract with directly. You get full control over routing and storage. You also take on everything else: the aggregator contract, 10DLC registration, delivery receipt parsing, retry logic, opt-outs, uptime and on-call. We compared this tradeoff in detail in open source SMS gateway vs a managed API. It only pays off at very high volume, with a team dedicated to it.

Phone or SIM gateways

Android apps and SIM-box hardware that send texts from a consumer phone plan are cheap and quick to set up. They're also not a business messaging route. Consumer plans aren't registered for A2P traffic, carriers filter or suspend these numbers when volume shows up, and you have no compliance tooling at all. Fine for a hobby project. Not something to put customer traffic on.

Good fit: carriers, aggregators and very large senders (SMPP), or prototypes that never touch real customers (SIM).

Ready API: registered numbers with the compliance layer included

Ready sits as a thin layer over carrier infrastructure. The difference from the raw CPaaS options is what ships by default rather than what you build.

What you don't have to build

  • Registration in-app and per sub-account. Each of your customers gets a sub-account with its own numbers and its own 10DLC brand and campaign. There is no setup fee: the charge at submit is the first month ($25), then $25/mo for registration and $2/mo per number. Most approvals take 2 to 7 days.
  • STOP propagation. Inbound STOP and UNSUBSCRIBE are honored, and the opt-out applies across campaigns. Sends to opted-out or numbers on your Ban list are refused up front and not charged. Check one number with GET /v1/opt-outs/:phone, the same answer Ready uses before a send. GET /v1/opt-outs lists this account's opted-out contacts only.
  • Quiet hours. An API or one-to-one text sent during the recipient's quiet hours is held and sent later if their window opens within about 6 hours; otherwise it is refused with 409 QUIET_HOURS_BLOCK and you send it again. Campaign and automation texts wait up to 24 hours. It's charged only when it actually sends.
  • Replies in an inbox. Inbound replies land in the Inbox and reach your app through webhooks. See the docs for setup, and our guide to receiving SMS via API for the inbound design.
  • Consent attestation. Each bulk send, and each API send that sets consent_attested, records the sender's attestation (who sent, to how many, when). This is an audit trail of your promise. It is not a per-contact consent record, so your app still needs to store each recipient's opt-in time, wording and source.

Optional extras are off by default: litigator and DNC scrubbing, and landline validation, at $0.003 per segment each when switched on.

What a send looks like

curl -X POST https://api.tryready.com/v1/messages \
  -H "X-API-Key: $READY_API_KEY" \
  -H "Idempotency-Key: <a new UUID for each text>" \
  -H "Content-Type: application/json" \
  -d '{"to": "+12125550199", "body": "Your appointment is confirmed for Tuesday at 10 AM. Reply C to cancel.", "consent_attested": true}'

The Idempotency-Key means a retried request never sends twice. Add "from_strategy": "local" to send from the registered number closest to the contact's area code. To read the thread back, call GET /v1/messages and page with before_id. The API reference covers keys and test keys.

Where Ready is not the right fit

If you have engineers who want to own the compliance layer, and your margin depends on per-segment price, Twilio or AWS will cost you less per text. Ready does not fail over between carrier providers, so if multi-provider failover is a hard requirement, build that on raw CPaaS.

Side-by-side comparison

AWS End User MessagingTwilioSelf-hosted gatewayReady API
Inbound repliesSNS topic → your codeWebhook to your URLParse SMPP yourselfWebhooks + inbox
10DLC registrationConsole/API, per tenant is yoursTrust Hub, per tenant is yoursThrough your aggregatorIn-app, per sub-account
STOP handlingOpt-out lists, keyword configAdvanced Opt-OutBuild itAutomatic, across campaigns
Quiet hoursBuild itBuild itBuild itBuilt in, held up to 6 hours (24 for campaigns), else refused
Conversation storageBuild itBuild itBuild itIncluded
Per-segment priceLow; check AWS pricing~$0.0083 + carrier feesAggregator rate + ops cost$0.0075 + $0.0045 carrier fee

Ready's all-in prices per segment include the carrier fee but not screening: Scrub lists and Number validation, the two switches in Settings under Compliance, each add $0.003 per segment when switched on, shown as screening on your bill, and both are off by default. Unless you turn the opt-out footer off, the first text to each contact, and one again from time to time, also gets "Reply STOP to opt out" and your business name if the message does not already have them, so a text close to the segment limit can bill one more segment.

Worked example: a month of two-way traffic

Here are the assumptions for this example. A platform sends 10,000 single-segment appointment reminders in a month (each under 160 GSM-7 characters, with no emoji), and 3,000 recipients reply with one segment each.

On Ready, replies bill like sent texts, so that's 13,000 segments:

  • Rate: 13,000 × $0.0075 = $98
  • Carrier fee: 13,000 × $0.0045, itemized separately on the bill
  • Registration for one brand, one campaign and one number: $27/mo

If you switched on scrubbing for the same traffic, that adds 13,000 × $0.003 = $39.

On Twilio, the same 13,000 segments at ~$0.0083 come to about $107.90 plus carrier fees and registration. That's real money saved. Against it, you put the engineering time to build per-tenant registration, cross-campaign opt-outs, quiet-hour holds and a thread store, and to maintain all of it as carrier rules change.

Watch for one detail on either platform: add a single emoji to that reminder and a 140-character message becomes 3 segments instead of 1. Your 10,000-send line triples.

How to choose

  • Already deep in AWS, sending mostly one-way alerts? AWS End User Messaging.
  • Messaging engineers on staff, and per-segment cost drives the decision? Twilio.
  • Carrier-scale volume with a dedicated team? A self-hosted SMPP gateway.
  • Platform texting for many customers, and you'd rather not build registration, opt-outs and quiet hours? Ready.

For more on designing the reply side regardless of provider, our two-way SMS API guide covers thread matching and reply handling.

The practical takeaway

Every provider here can send and receive a text. They differ in how much of the surrounding compliance work lands on your team. If you want to see how the Ready side feels, create an account. A card on file is required, and your first 20 one-to-one texts are free, so use them to test sends and replies before you pay for registration. Pricing is on the pricing page, and the full API reference is at docs.tryready.com.