SMS gateway vs SMS API vs email-to-SMS: which does a business need?

"SMS gateway" is one of the most overloaded terms in messaging. Vendors use it for at least three different things. Forum threads use it for a fourth. Buyers searching for one often end up comparing a USB modem, an email address ending in a carrier domain, and a cloud API as if they were interchangeable. They are not. They differ in who the carriers think is sending, whether the traffic is registered, and what happens when you go from 50 texts to 50,000.

This post separates the terms and shows what each approach delivers. It explains why hardware and email gateways fail once real volume or real customers are involved, and it lays out the case for a registered API with a worked cost example. We make Ready, a registered SMS API and platform, so we have a side in this. We'll also say where the other options are fine and where another API costs less per segment.

The three things people mean by "SMS gateway"

1. Carrier email-to-SMS gateways

US carriers have historically run email addresses that turn an email into a text. You send to 5551234567@ plus the carrier's gateway domain, and the message lands as an SMS. The service is free and needs no account. It is also a consumer convenience feature, not a business channel:

• You have to know which carrier each recipient uses, and ported numbers break that.
• You get no delivery receipts, no reliable two-way replies and no STOP handling.
• Carriers rate-limit and filter it heavily, and some have shut theirs down. AT&T retired its email-to-text gateway in 2025.

2. Hardware gateways: GSM modems, SIM banks and phone apps

This is the "build your own" route. A USB modem, a rack of SIMs, or an old Android phone running a gateway app sends texts from consumer SIM cards, with an HTTP endpoint wrapped around it. We cover the build in more depth in SMS gateways explained. The self-hosted software side (Jasmin and friends) is covered in open source SMS gateway vs a managed SMS API.

3. "Gateway" as a synonym for an SMS API provider

Many cloud providers call themselves an "SMS gateway". In practice they are SMS APIs: you send an HTTP request, they deliver over carrier connections, and the sender is registered (or should be). When a vendor says "gateway API", this is usually what they mean.

Email-to-SMS: what it's good for and where it stops

Email-to-SMS comes in two flavors, and the distinction matters:

• Carrier email gateways (above): unregistered, unmonitored and increasingly unavailable.
• Provider email-to-SMS: some SMS providers accept an email and convert it into a send over their registered routes. Under the hood this is an API send with an email front end, so it inherits the provider's registration and opt-out handling.

The carrier version is reasonable for one narrow job: a handful of internal alerts to your own staff's phones, where nobody minds if one goes missing. It is not acceptable for customer messaging. You can't prove delivery, you can't honor opt-outs across messages, and carriers treat bulk use of it as spam.

Hardware gateways: why they break at scale

A modem or SIM bank feels attractive because the per-text cost looks like zero on an unlimited plan. The problems are structural, not tuning issues.

It's the wrong traffic class. A consumer SIM is licensed for person-to-person (P2P) messaging. A business sending reminders or promotions from software is application-to-person (A2P) traffic. In the US, A2P on local numbers is supposed to run over 10DLC. Every brand and campaign is registered with the carriers. A consumer SIM can't be registered as a 10DLC campaign, so its A2P traffic is unregistered by definition.

Carriers detect it. Identical content from one SIM at machine speed is exactly the pattern carrier filters look for. Messages get silently filtered, and then the SIM gets suspended. Teams end up rotating SIMs to stay ahead of blocks. That is a sign the approach has already failed.

Throughput is capped by physics. Each SIM sends one message at a time over a radio link. Adding capacity means adding SIMs, which means more numbers that look like a spam farm.

You rebuild compliance yourself. STOP keywords, opt-out propagation across every SIM, quiet hours, delivery receipts and retry logic all become your code. Each missing piece is a TCPA exposure. Statutory damages run $500 to $1,500 per text.

Hardware still has legitimate uses. Lab testing, a private IoT device texting its owner, and hobby projects are all fine. Customer-facing business messaging is not one of them.

SMS API: what you get that the others can't give you

A registered SMS API sends your traffic as declared A2P. You register a brand and campaign once, and carriers then know who you are and what you send. Here's the practical difference:

Throughput on a registered route is approximate, because carriers publish no official rate card. A fresh standard 10DLC campaign typically gets around 1 to 4 segments per second. T-Mobile also applies a daily brand cap tied to trust score, from roughly 2,000 messages a day at the lowest tier up to roughly 200,000 at the highest. Optional brand vetting ($79 Standard / $179 Enhanced, one-time) can raise the trust score. Most senders don't need it.

Picking a sender type (10DLC, toll-free or something else) is its own decision. Our 10DLC vs toll-free vs long code vs RCS post covers it.

What a send looks like

On Ready, one text is one request:

POST https://api.tryready.com/v1/messages
X-API-Key: <your key>
Idempotency-Key: 6f1c2a9e-0b7d-4e3a-9c41-2d8f5b7a1e10

{"to": "+12125550199", "body": "Your order #1042 has shipped.", "consent_attested": true}

The Idempotency-Key means a retried request never sends twice. 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 goes out, but an API text is held only if the window opens within 6 hours; otherwise it is refused and must be resent. For lists, POST /v1/messages/bulk takes up to 100 recipients per call. Full reference: docs.tryready.com/api/messages.

Worked example: what a registered API actually costs

Assumptions, labelled as such: a business sends 2,000 one-to-one appointment reminders a month. Each is under 160 plain characters with no emoji, so each is 1 segment. It uses one number on Ready Standard.

• Sends: 2,000 × $0.0075 = $15, plus 2,000 × $0.0045 in carrier fee.
• Replies: inbound replies bill like sent texts. If roughly 30% reply with one segment, add 600 × ($0.0075 + $0.0045).
• Registration: $25 charged at submit (that's the first month, with no setup fee). After that it's $25/mo for registration + $2/mo per number, so $27/mo with one number.

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.

That total is the per-segment rate plus carrier fee.

Now the honest comparison. Twilio's per-segment rate is around $0.0083, and GoHighLevel/LeadConnector runs around $0.0128 all-in. Both are lower per message than our Standard rate. If you have engineers who want to assemble registration, opt-out storage, quiet hours and an inbox themselves, a raw CPaaS is a reasonable choice. Our best SMS API for developers post compares them directly.

What you get with Ready instead is in-app registration (most approvals take 2 to 7 days), automatic STOP propagation, quiet hours, optional litigator/DNC scrubbing, and an Inbox. Against a SIM gateway "costing nothing", the real comparison is filtered messages, suspended SIMs and unhandled opt-outs.

If you're a platform texting for your customers

Most "gateway vs API" research comes from someone building texting into a product: a CRM, a scheduling tool, a vertical SaaS. Hardware and email gateways are a non-starter here. You'd be sending every customer's traffic from the same unregistered pool, so one bad sender takes everyone down.

The pattern that works is one sub-account per customer, each with its own numbers and its own 10DLC registration. That way one customer's content or complaint rate can't affect another's deliverability. On Ready, sub-accounts are created with POST /v1/sub-accounts, and registration status is readable at GET /v1/registration. Our SMS API for SaaS platforms checklist goes through what else to check before embedding texting. If your customers live in GoHighLevel, Ready also installs natively there with two-way sync per GHL location.

Compliance stays the sender's responsibility. A registered API reduces risk; it doesn't make anyone immune. Your customers still need real opt-in, and consent_attested: true is their promise that the recipient agreed to texts.

Which one you actually need

• A few internal alerts to your own team's phones: a carrier email gateway may still work where available. Don't build anything on it.
• Testing, IoT or hobby projects: a GSM modem or phone app is fine.
• Any texting to customers, leads or patients: use a registered SMS API. Choose between a raw CPaaS (lower per-segment rate, more to build) and a platform like Ready (registration, compliance and inbox included).
• A software platform texting on behalf of customers: use a registered API with per-customer sub-accounts and registrations.

If you want to try the API route, sign up and send your first 20 texts free. They're one-to-one sends, and to send any text you need a card and a number ($2 a month, the first month charged when you get it). Use them before you register, since they end when a registration is paid for. The quickstart gets a first message out in a few minutes.