SMS API for SaaS platforms: what to check before you embed texting

Before you pick an SMS API for SaaS, check that it gives each of your customers a separate sub-account with its own numbers and 10DLC registration, and that it handles opt-outs, scrubbing, quiet hours and webhooks without you building them. Per-segment price matters too, but the bigger cost is usually the compliance and tenancy work the API leaves for your engineers.

This post is the checklist we would use if we were embedding texting in a product today. We make Ready, so we have a stake in the answer. We also say plainly where Twilio costs less and where it is still the better choice. Some teams should use a raw carrier API, and the math below shows which ones.

Why texting for your customers is different from texting your own users

Sending your own password resets is one sender with one brand. Letting 300 customers text their customers through your product is 300 senders. Carriers treat it that way, and so do regulators.

That changes several things:

• Registration. Each customer usually needs its own A2P 10DLC brand and campaign. Traffic that isn't registered gets carrier-filtered. We cover who registers what in 10DLC for SaaS platforms.
• Reputation isolation. One customer sending junk shouldn't throttle everyone else's numbers.
• Opt-outs. A STOP sent to one customer's number has to be honored for that sender, every time, across every campaign.
• Billing. You pay the provider, and you have to charge your customers. The invoice needs to be readable enough for you to mark it up.

A plain send endpoint covers none of that. The checklist below goes through each item.

The SMS API for SaaS checklist

1. Per-customer sub-accounts

Ask whether each of your customers can be a real sub-account with its own numbers, registration and contacts. On Ready, opt-outs are shared on purpose: a STOP to any sub-account blocks that number for the parent account and every sub-account. A tag on a shared account is not the same thing. You want to create these from your own signup flow, not from a vendor dashboard.

On Ready, sub-accounts are part of the API: GET /v1/sub-accounts lists them and POST /v1/sub-accounts creates one. Numbers work the same way, with GET /v1/numbers and POST /v1/numbers. Details are in the docs.

2. Registration you can drive from your product

Brand and campaign registration is where most embedded-texting projects stall. The forms are fussy, rejections are vague, and your customers will not enjoy filling them in on a carrier portal.

Things to check:

• Can registration be submitted and tracked per sub-account?
• Can you read the status programmatically to show "pending" or "approved" in your UI?
• What does it cost, and is there a setup fee?

On Ready, registration is handled in-app per sub-account, and GET /v1/registration returns its status. The fees are $25/mo for registration and $2 per number. There's no setup fee: the charge at submit is the first month, $25. Most approvals take 2 to 7 days. While a registration is in review, an account that has already bought its number sends on Ready's shared registration at its normal per-text rate. Before registering at all, an account can send up to 500 texts a month. For the registration API itself, see docs.tryready.com/api/registration rather than our summary here.

Brand vetting ($79 Standard / $179 Enhanced, one-time) is optional. It raises the trust score, which can move a brand to a higher T-Mobile daily cap (roughly ~2,000 up to ~200,000 messages/day by tier). Most of your customers won't need it. The ones sending real volume might.

3. Opt-out handling that you don't maintain

STOP handling looks easy until you hit the edge cases: "Stop.", "UNSUBSCRIBE", a STOP sent during a drip campaign, or a contact imported again a month later. Ask:

• Is inbound STOP honored automatically?
• Does the opt-out apply to every campaign for that sender, not only the one it arrived on?
• Are sends to opted-out numbers refused at the API, or do they go out and get you in trouble?
• Can you read the opt-out list to sync it back to your own database?

On Ready, an inbound STOP/UNSUBSCRIBE is honored and the opt-out propagates so the contact can't be messaged again across campaigns. Sends to opted-out numbers are refused up front and not charged. GET /v1/opt-outs lists the opted-out contacts on an account, so you can show them in your UI. It is not a complete mirror (a STOP from a deleted contact, a dialer do-not-call entry or a STOP on another sub-account of the same parent is left out), so check GET /v1/opt-outs/:phone before a send from another tool. If you're deciding whether to build this yourself, read SMS opt-out API: handle STOP without building it yourself first.

4. Quiet hours, scrubbing and validation

These three reduce TCPA exposure for your customers. TCPA damages run $500 to $1,500 per text, and some of that risk can land on you as the platform that sent it.

• Quiet hours. On Ready, campaigns, drip campaigns and automations wait up to 24 hours for the recipient's window (based on their area). A one-to-one or API text is held only if the window opens within 6 hours; otherwise it is refused with 409 QUIET_HOURS_BLOCK and must be resent. A held text is charged only when it sends.
• Litigator and DNC scrubbing. GET /v1/scrub/:phone checks a number against known TCPA-litigator and DNC-complainer lists. The standalone scrub is $0.005 per contact. You can also switch scrubbing on for an account as a $0.003 per-segment surcharge on each send. It's off by default.
• Number validation. GET /v1/validate/:phone tells you whether a number is mobile, landline or disconnected. Landline validation on sends is another $0.003 per segment when switched on, also off by default. Known landlines are refused up front and not charged.

None of this makes anyone lawsuit-proof. Compliance stays the sender's responsibility. Ready also records the sender's opt-in attestation per bulk send and per API send that sets consent_attested (who sent, to how many, when). That record is an audit trail of sends. It is not a per-contact consent record. Your product, or your customer's, still has to store when and how each person opted in.

5. Webhooks and idempotency

You'll want delivery status and inbound replies pushed to your app, and you'll want retries that never double-send. Check the webhook coverage in the provider's docs. Then check whether the API supports an idempotency key.

Ready supports an Idempotency-Key header. Send any UUID, and a retried request won't send twice:

curl -X POST https://api.tryready.com/v1/messages \
  -H "X-API-Key: $READY_API_KEY" \
  -H "Idempotency-Key: 7d4f1c2e-9b3a-4e8f-a1c6-2f5d8e0b3a91" \
  -H "Content-Type: application/json" \
  -d '{"to": "+12125550199", "body": "Your order #1042 has shipped.", "consent_attested": true}'

consent_attested is your promise that the recipient agreed to texts. For webhook setup, see docs.tryready.com/api/webhooks. For sending the same text to many numbers, see bulk messages.

6. Throughput you can explain to customers

Your customers will ask why a 10,000-contact campaign took an hour. Carriers meter by segments per second per campaign. A fresh standard campaign with no vetting often gets roughly 1 to 4 per second, and higher use-case tiers get tens. At an assumed 3 segments per second, 10,000 single-segment texts take about 55 minutes. Put that number in your UI before support tickets do it for you.

7. Billing you can pass through

Ready bills prepaid credits via Stripe, with carrier fees itemized separately, so you can see what's markup and what's carrier cost. Inbound replies are billed like a sent text, so model them in. If customers reply at, say, a 30% rate on a two-way campaign, that's 30% more segments than your outbound count suggests.

Segment math your pricing page needs

Segments get billed, not messages. Customers will paste emojis into everything, so your pricing should account for it:

Ready swaps curly quotes, long dashes and ellipses for plain ones before sending, so those don't silently push a message into Unicode. Emojis still do.

Worked example. A customer sends a 175-character promo with an emoji to 5,000 consented contacts on Standard: 5,000 × 3 = 15,000 segments. At $0.0075/segment that's $300, plus 15,000 × $0.0045 in carrier fees. Without the emoji it's 10,000 segments, so $200 plus 10,000 × $0.0045. That's a third off the rate cost for deleting one character. A character counter in your composer pays for itself.

Where Twilio still wins

Twilio is priced at about $0.0083/segment. Ready Standard is $0.0075/segment plus a $0.0045 carrier fee, and that excludes the optional compliance surcharges above. Telnyx, Plivo and Bandwidth have similar underlying carrier cost to Twilio. A raw CPaaS costs less per segment, and we won't pretend otherwise. The full breakdown is in Ready vs Twilio in 2026.

Worked example, with stated assumptions. Say 200 customers each send 2,000 segments a month, for 400,000 segments total.

• Twilio rate: 400,000 × $0.0083 = $3,320/month, before Twilio's own carrier and registration fees.
• Ready rate: 400,000 × $0.0075 = $3,000/month, plus 400,000 × $0.0045.

The rate gap is about −$320/month, or roughly $56,000/year. Against that, put the work you'd own on a raw API: sub-account provisioning, registration flows and rejection handling, cross-campaign opt-outs, quiet-hours holds, litigator scrubbing, validation and itemized billing. If that work took one engineer half their time at an assumed $180,000 loaded cost, it would come to about $90,000/year, plus the ongoing upkeep when carrier rules change. Your numbers will differ, so plug in your own.

Pick Twilio or another raw CPaaS if:

• You send high volume and the per-segment gap dwarfs engineering cost. At 4 million segments a month, the gap above becomes about $562,000/year.
• You already have a telecom team and compliance tooling.
• You need channels or countries Ready doesn't focus on. Ready is US-focused texting, and Twilio's catalog is far broader.

Pick Ready if you want sub-accounts, registration, opt-outs, quiet hours and scrubbing to come with the API, and you'd rather ship texting this quarter than staff a telecom project.

iMessage: worth asking about

Some providers now offer business iMessage. Ready's iMessage line sends texts as iMessage, so they show up blue on iPhones with the business's name and photo. It needs no 10DLC registration, so a customer can start texting as soon as the line is set up, which helps while their registration is in review.

Pricing is $99 a month per line, plus 6 cents a segment sent. A reply to an iMessage line is also 6 cents a segment, and reactions are free. Texts to Android phones go from the account's regular number. If the account already had a number, they bill at the regular text price; if the iMessage line came with its green number, the account's texts bill at 6 cents a segment once it registers or sends through GoHighLevel (see the iMessage line guide).

There are limits:

• Each line can start up to 50 new conversations a day.
• Up to 2 texts can go to someone until they reply.
• Photos can be sent only after a reply.
• Campaigns and drip campaigns send from regular numbers, not the iMessage line.

iMessage line replies land in the same inbox thread as SMS. It's built for one-to-one conversations, not campaigns. More in SMS API with iMessage and the iMessage line docs.

The practical takeaway

Price your SMS feature on segments, not messages, and on the full stack, not the per-segment rate alone. If you have the volume and the team, a raw CPaaS is cheaper to run. If you'd rather not build tenancy, registration and opt-out plumbing, a platform that includes them saves engineering time even though the per-segment rate is higher.

To try Ready, sign up with a card on file. The first 20 texts are free for one-to-one sends, so test your integration before you pay for registration. Campaigns are paid from the first text. Pricing is on the pricing page.

FAQ

What is the best SMS API for a SaaS platform? The best one gives each of your customers its own sub-account, numbers and 10DLC registration, and handles opt-outs and compliance for you. If you have a telecom team and high volume, a raw CPaaS like Twilio costs less per segment. If you don't, an API that includes those layers usually costs less overall.

Do my SaaS customers each need their own 10DLC registration? Usually yes, because each customer is a separate sender in the carriers' eyes. Shared registration across unrelated businesses tends to get filtered. On Ready, registration runs per sub-account and most approvals take 2 to 7 days.

Is Twilio cheaper than other SMS APIs? Per segment, Twilio is among the cheapest at about $0.0083/segment. That price covers sending, not the sub-account, registration, opt-out and scrubbing logic you'd build around it. Compare the total cost, including engineering time.

How should a multi-tenant app handle STOP replies? Honor every STOP automatically for that sender, across every campaign, and refuse later sends to that number. Show the opt-out list in your UI, but check each number before sending from another tool. On Ready, opted-out numbers are refused up front and not charged, and GET /v1/opt-outs/:phone answers what the send gate enforces.

Can a SaaS app send iMessage instead of SMS? Yes, through a business iMessage line such as Ready's iMessage line, which can text first and needs no 10DLC registration. It costs $99 a month per line plus 6 cents a segment. Each line can start up to 50 new conversations a day, and Android contacts get regular SMS.