What is an SMS gateway? How apps reach carriers, and what to check

An SMS gateway is the service that takes a message from your software, usually as an HTTP request, and hands it to the mobile carrier networks that deliver it to a phone. It also works in reverse: replies and delivery receipts come back through the gateway to your app as webhooks.

That definition is the easy part. What you actually buy when you pick a gateway is the set of rules it enforces and leaves out, and what it charges per segment. A gateway that only moves bytes leaves you to build carrier registration, opt-out handling, quiet hours and number validation yourself. A gateway that handles those leaves you less to build, and you pay a little more per text for it. This post explains how gateways work, how they differ from aggregators and platforms, and what to check before you choose one.

How an SMS gateway gets a text from your app to a phone

Here is the path a single text takes from your code to a handset:

1. Your app sends a request. It is usually a REST call with a destination number, a message body and the number you're sending from.
2. The gateway checks the request. It validates the number format and confirms the sending number belongs to you. A good gateway also refuses numbers that have opted out.
3. The gateway counts and encodes segments. It decides whether the body fits GSM-7 or needs Unicode, then splits long messages into billed segments.
4. The gateway routes the message to a carrier. It goes over SMPP or a similar protocol to an aggregator or a carrier, tagged with your 10DLC campaign so the carrier knows who is sending and why.
5. The carrier delivers the text, or filters it. Unregistered or suspicious traffic gets blocked here, often without telling anyone.
6. The status comes back. A delivery receipt travels back up the chain, and the gateway fires a webhook to your app. Inbound replies follow the same route.

On Ready, step 1 looks like this:

curl 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 order #1042 has shipped.", "consent_attested": true}'

The Idempotency-Key means a retried request after a timeout won't send the text twice. consent_attested is your promise that the recipient agreed to receive texts. Full reference: docs.tryready.com/api/messages. If you want the step-by-step build, see how to integrate an SMS API into your app.

Gateway vs aggregator vs platform

People use these three words loosely, and vendors use them to sound bigger or smaller than they are. Here is a working distinction:

There is also an older meaning of "SMS gateway": an Android phone or a SIM-box that sends texts from a consumer SIM, often controlled by an app. It's cheap, and it's the wrong tool for business messaging in the US. Carriers treat high-volume application traffic from consumer lines as unregistered A2P traffic and filter it. If you're unsure which side of that line your texts fall on, our explainer on A2P vs P2P messaging covers it.

What 10DLC registration changed about gateways

Before A2P 10DLC, a gateway could send almost anything from a regular 10-digit number. Now US carriers expect every business text from a local number to be tied to a registered brand (the company) and a registered campaign (the use case, with sample messages). Unregistered traffic gets carrier-filtered.

For a single business, that's one form to fill out. For a platform texting on behalf of hundreds of customers, it's a product problem. Each customer needs its own brand, its own campaign and its own numbers, and someone has to collect the business details, submit them, follow the status and fix rejections.

Most bare gateways give you the registration API calls and leave the workflow to you. Ready handles brand and campaign registration in the app and over the API. Each customer gets a sub-account with its own numbers and registration. You can check status with GET /v1/registration. Registration has no setup fee. The charge when you submit is the first month, $25. After that, the monthly cost is $25/mo for registration + $2 per number. Most approvals take 2 to 7 days. For the multi-tenant side, see the 10DLC registration API walk-through.

Throughput: the speed limit sits above the gateway

A common surprise is that your gateway accepts 10,000 requests in a minute, but the texts trickle out. The limit usually isn't the gateway. Carriers cap throughput per campaign, and they don't publish an official rate card. The figures below are round approximations:

• Per-second rate: about 1 to 4 segments per second for a fresh standard campaign with no vetting, and tens (roughly 10 to 75) for higher use-case tiers.
• T-Mobile daily brand cap by trust score: about 2,000, 10,000, 40,000, 100,000 or 200,000 messages a day, lowest score first.
• AT&T throttles per second and per minute rather than with a hard daily cap.

Here is a worked example, assuming 3 segments per second. A 6,000-segment campaign takes 6,000 ÷ 3 = 2,000 seconds, a little over 33 minutes, no matter how fast your code calls the API. Brand vetting ($79 Standard / $179 Enhanced, one-time) can raise 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. More detail in SMS API rate limits.

What a text costs through a gateway

Every gateway bills by segment, not by message. A segment is 160 GSM-7 characters, or 153 per part once a message splits. A single emoji switches the whole message to Unicode, which drops the limit to 70 characters (67 per part). On Ready, curly quotes, long dashes and ellipses are swapped for plain ones before sending, so they never change the count.

Worked example (assumptions stated):

• An order-update message of 120 characters with no emoji is 1 segment. Sent to 1,000 customers on Ready's Standard rate, that's 1,000 × $0.0075 = $8, plus 1,000 × $0.0045 = $4.50 in carrier fees, $12.00 in all.
• Add one emoji to a 140-character version and it becomes 3 segments. The same 1,000 sends now cost 3,000 × $0.0075 = $23, plus 3,000 × $0.0045 = $13.50, $36.00 in all.

That emoji tripled the bill. Replies you receive are billed the same way, at the per-segment rate plus the carrier fee.

The $0.0075/segment plus $0.0045 figure doesn't include the compliance surcharge. TCPA/DNC scrubbing and landline validation are each $0.003 extra per segment when you switch them on for an account. Both are off by default.

To be plain about it: if per-segment price is your only criterion, raw CPaaS APIs like Twilio or Telnyx charge less per segment than we do. What you're comparing is how much of the stack in this post you'd have to build on top of them. SMS API pricing explained breaks down the line items.

What to check before you pick an SMS gateway

Here are the questions that separate gateways in practice:

1. Registration: Does it register brands and campaigns for you, or only expose the carrier forms? Can it register separately for each of your customers?
2. Multi-tenancy: Can each customer have isolated numbers and billing (sub-accounts), or do they all share one pool?
3. Opt-outs: Is STOP honored automatically, and does it carry across every campaign? On Ready, opted-out numbers are refused up front and not charged. You can list this account's opted-out contacts with GET /v1/opt-outs.
4. Quiet hours: Are sends held outside permitted local hours for the recipient's area? On Ready, a held text sends later and is charged only when it sends. Campaigns, drip campaigns and automations wait up to 24 hours for the window; 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 one-to-one reply to someone who texted you in the last 24 hours goes out at any hour.
5. Number validation: Can you check whether a number is mobile, landline or disconnected before you send? On Ready, known landlines are refused up front on every account, landline validation ($0.003 per segment, off by default) adds a send-time lookup, and GET /v1/validate/:phone checks one number on demand.
6. Litigator and DNC screening: The standalone scrub is $0.005 per contact. It screens numbers against known TCPA-litigator and DNC-complainer lists. TCPA exposure runs about $500 to $1,500 per text, so this is cheap risk reduction. It is not lawsuit-proofing.
7. Duplicate protection: Does the API accept an idempotency key?
8. Pricing: Is the bill readable, with segments, carrier fees and add-ons itemized separately?

For a longer version aimed at procurement, see how to choose a CPaaS SMS provider.

One caveat applies to every gateway. These tools reduce risk, but compliance stays the sender's responsibility. Ready records the sender's opt-in attestation for each bulk send and each API send that sets consent_attested: who sent, to how many, and when. It doesn't store a per-contact consent record such as the recipient's opt-in time, wording or page URL. Your app needs to keep that. (A contact who signs up on a Ready-hosted opt-in page is the exception: Ready stores that sign-up, with the time, IP address and exact wording, and support@tryready.com can send you a copy.)

Where Ready fits, and where it doesn't

We make Ready, so here is the honest version. Ready is a messaging API and platform built for software companies that text on behalf of their customers: CRMs, vertical SaaS products and other platforms. Each customer gets a sub-account with its own numbers and 10DLC registration. SMS and iMessage (the "blue line") go through one REST API, with TCPA and DNC scrubbing, number validation, opt-out handling and webhooks built in. It also installs natively into GoHighLevel, and teams use the Ready app directly without writing code.

Ready is the wrong fit if you have engineers who want raw carrier routes, you'll build registration and compliance yourself, and per-segment cost outweighs everything else. A bare CPaaS is fine for that.

To try it, the first 20 texts are free. They're one-to-one sends; a campaign is paid from the 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 registering, at its normal rate. The free texts end the moment you pay for a registration, so use them first. The API quickstart gets you to a first API send.

The short version

An SMS gateway moves your app's messages onto carrier networks and brings replies back. Since 10DLC, the plumbing is the smaller part of the job. The bigger part is registration, opt-outs, quiet hours and validation. Decide which of those you want to build, then choose a gateway, aggregator or platform to match. Run the segment math on your real message templates before you compare prices, because emoji and length change the bill more than most rate differences do.

FAQ

Is an SMS gateway the same as an SMS API?

Mostly, yes. The API is the interface you call, and the gateway is the service behind it that routes to carriers. Some vendors only sell the gateway layer. Others add registration and compliance on top.

Can I use my phone as an SMS gateway for business texts?

Not for US business messaging at any real volume. Carriers expect application-to-person traffic to come from registered 10DLC numbers, and texts sent through a consumer SIM tend to get filtered.

Do I need 10DLC registration to use an SMS gateway?

You need it for business texting from local US numbers. On Ready, an account can send up to 500 texts a month before registering. If you bought a number before registering, you send on Ready's shared registration while your own is in review.

Does a gateway handle STOP replies automatically?

Some do and some leave it to you. On Ready, inbound STOP and UNSUBSCRIBE are honored automatically, and the opt-out applies across all campaigns.

How fast can a gateway send?

As fast as carriers allow your campaign. Roughly 1 to 4 segments per second for a fresh standard campaign, and tens per second for higher tiers. These are approximations, since carriers publish no official rate card.