SMS gateway API for notifications and bulk sending: how to pick one

Sending one text from code takes about ten minutes with any SMS gateway API. The harder parts show up later:

• the order-shipped alert that went out twice because a worker retried
• the "delivered" status that only meant the carrier accepted the message
• the 5,000-contact campaign that is still trickling out an hour after you hit send
• the trial account that worked in staging and got filtered in production

This guide is for developers who are wiring notifications and bulk sends through a gateway API and need to choose one. It covers what a gateway is compared with a direct carrier connection, what delivery reporting can and can't tell you, the segment and throughput math that sets your bill and your send time, and the free-tier traps to check before you commit. We make Ready, so we'll show how we handle each of these. We'll also say where a raw CPaaS API is the better fit.

Gateway API vs direct carrier API

A "direct carrier API" is mostly a myth for application developers. US carriers don't hand out connections to individual apps. Traffic reaches them through aggregators, which hold the carrier connections, and SMS gateways and CPaaS providers sit on top of those aggregators. When a vendor says "direct to carrier," ask what that phrase means in practice. Usually it means fewer hops, not no hops.

In practice you're choosing between four layers:

On price per segment, Twilio and the other raw CPaaS APIs come in below our Standard rate of $0.0075/segment plus a $0.0045 carrier fee. If you only need a pipe and you're happy to build registration, STOP handling and per-customer isolation yourself, a raw CPaaS is a reasonable choice. Our pitch is the work you don't have to build: each of your customers gets a sub-account with its own numbers and its own 10DLC registration, and every send passes through the compliance layer before it reaches carrier infrastructure.

Notifications and bulk are different workloads

Many teams pick one gateway for "SMS" and only later find out that alerts and campaigns behave differently.

Notifications: latency and exactly-once

Transactional alerts (order shipped, appointment tomorrow, password reset) go to one person each, and they need to arrive quickly and only once. The feature that matters most is idempotency. Your job queue will retry, and without a guard every retry becomes a second text, billed and annoying. On Ready, you send an Idempotency-Key header with any UUID, and a retried request never sends twice:

curl -X POST https://api.tryready.com/v1/messages \
  -H "X-API-Key: $READY_API_KEY" \
  -H "Idempotency-Key: 3f6c1e2a-9b7d-4c1e-8a55-0d2f4b6a9e11" \
  -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 receive texts. We record that attestation for each send (who sent it, to how many people, when), which gives you an audit trail of what you attested. It is not a per-contact consent record. Your app still needs to store each recipient's opt-in time, the wording they agreed to, and the page URL. For more on retry patterns, see how to stop duplicate texts from your SMS API.

Bulk: batching, pacing and consent

A bulk send is one message to many recipients. Ready's endpoint is POST /v1/messages/bulk, which takes a to array of up to 100 recipients per call, so a 5,000-contact list becomes 50 batched calls. The real limit on a bulk send isn't your loop speed. It's the carrier caps covered below. Bulk sends should only go to consented or replied contacts. Cold outreach belongs on the phone or in the mail, not in a texting campaign. The bulk SMS API guide walks through batching in detail.

Delivery reporting: what "delivered" actually means

Compare gateways on delivery reporting, because it's where they differ most and where the marketing pages say the least.

Accepted, sent and delivered are different events

A successful API response means the gateway accepted your request. A later status may mean the message reached the carrier. A handset delivery receipt, when one exists, comes back from the carrier, and receipt quality varies by carrier and route. Build your alerting on the assumption that "no delivery receipt" does not mean "not delivered."

Questions to ask any vendor:

1. Do status changes arrive by webhook, or do you have to poll?
2. Can you list sent messages with paging, so you can reconcile them against your own records?
3. Are refused sends (opt-outs, numbers on your Ban list) rejected up front or charged and then dropped?
4. Do inbound replies arrive through the same webhook system as status updates?

On Ready, you read history with GET /v1/messages (paged with before_id) and check opt-outs with GET /v1/opt-outs or GET /v1/opt-outs/:phone. Opt-outs and numbers on your Ban list are refused up front and not charged. A text sent during the recipient's quiet hours is held and charged only when it actually goes out, but an 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. Webhook payloads are documented in the webhooks docs. For inbound handling, see receiving SMS via API.

One billing detail: replies you receive are billed like a sent text, at the per-segment rate plus the carrier fee. Include that in any budget for two-way alerts.

The segment math that sets your bill

Every gateway bills by segment, not by message, so the content of each text drives cost.

• Plain GSM-7 text: 160 characters fit in one segment. Longer messages split into 153-character segments.
• One emoji or other non-GSM character drops the limit to 70 characters, or 67 per segment for multipart messages.
• Ready converts curly quotes, long dashes and ellipses to plain characters before sending, so pasted copy doesn't quietly switch a message into unicode.

Worked example: notifications. Assume a 120-character shipping alert in plain text, which is 1 segment, sent to 20,000 customers a month:

• 20,000 × $0.0075 = $150 in Ready's rate
• plus 20,000 × $0.0045 in carrier fees

Add one emoji and the same 120 characters becomes 2 segments, so the Ready portion doubles to $300. That figure is "all-in" except for the compliance surcharge. TCPA/DNC scrubbing and landline validation each add $0.003 per segment when switched on for an account. Both are off by default.

Worked example: bulk. Assume a 175-character promo sent to 5,000 opted-in contacts:

• In plain text, it's 2 segments: 10,000 segments × $0.0075 = $75, plus 10,000 × $0.0045.
• With an emoji, it becomes 3 segments: 15,000 × $0.0075 = $113, plus 15,000 × $0.0045.

For a fuller pricing breakdown, the SMS API pricing explainer goes line by line.

Throughput: why your campaign takes an hour

Carriers cap throughput per 10DLC campaign, and they don't publish an official rate card, so treat these figures as approximations:

• A fresh standard campaign with no vetting usually gets about 1 to 4 segments per second. Higher use-case tiers get tens per second, roughly 10 to 75.
• T-Mobile also caps messages per day by brand trust score, at roughly ~2,000, ~10,000, ~40,000, ~100,000 or ~200,000, with the lowest score getting the lowest cap. AT&T throttles per second and per minute instead.

At an assumed 3 segments per second, the 15,000-segment emoji campaign above takes about 5,000 seconds, which is over 80 minutes. If your brand sits at the lowest T-Mobile tier, a 5,000-recipient send won't finish to T-Mobile subscribers in one day.

Optional brand vetting ($79 Standard or $179 Enhanced, one-time) raises your trust score. It only moves the daily cap if the new score crosses a tier, and it doesn't change the per-second rate. Most senders don't need it. See why your texts send slower than your code for queue design.

Free-tier traps to check

Trial tiers are meant to get you to "hello world," and some behave differently in production. Before you build on one, check:

• Recipient restrictions. Some trials only send to numbers you've verified, so the staging demo works and the first real customer gets nothing.
• Unregistered traffic. US carriers filter unregistered 10DLC traffic. A free tier that skips registration has deferred the problem, not solved it.
• What actually counts as free. Ask whether free covers campaigns or only one-to-one sends, whether a card is required, and when the free allowance ends.

Here is how Ready's free allowance works:

• The first 20 texts are free, and they're one-to-one sends. A campaign is paid from its first text.
• To send, you add a card and get a number, which is $2 a month with the first month charged when you get it.
• An account can send up to 500 texts a month before it registers, at its normal per-text rate. Past that, it has to register.
• The free texts end the moment a registration is paid for, so use them before you register.

Registration has no setup fee. At submit you pay the first month, $25. After that the monthly cost is $25/mo for registration, and $2 per number. Most approvals take 2 to 7 days. If you bought a number before registering, you can send on our shared registration at the same per-text rate while your own registration is in review. Platforms can drive this per sub-account through the API. Check status with GET /v1/registration, and see the quickstart for setup.

A short checklist before you pick

1. Does the API support idempotency keys?
2. Are opt-outs enforced across every sender and campaign automatically?
3. Are refused sends rejected up front and not charged?
4. Are quiet hours enforced by the recipient's area code?
5. Can you isolate each customer in a sub-account with its own numbers and registration?
6. Can you add scrubbing ($0.005 per contact standalone) or landline validation when you need them, rather than paying for them on every send?
7. Can you see per-segment pricing, with carrier fees itemized, before you sign?

If items 1 to 5 are things you'd rather build yourself, a raw CPaaS will cost less per segment. If you'd rather not build them, create an account, send your 20 free one-to-one texts against the messages API, and compare the results with your current setup before you move any traffic.