Your texts send slower than your code because carriers meter delivery per 10DLC campaign, usually at a few segments per second for a new campaign. T-Mobile also caps how many messages your brand can send per day. Your API call returns in milliseconds, but the real sms api rate limits sit downstream in the carrier network, and no HTTP client can speed them up.

This post is for the developer who wrote a loop over 50,000 contacts, watched every request return 200, and then got a support ticket three hours later asking why half the list hasn't received anything. We'll cover where the limits come from, which numbers are fixed and which you can move, and what a realistic send schedule looks like with the math shown.

Where SMS API rate limits actually live

Three different limits get blurred together under "rate limit." They behave differently, so it helps to separate them:

  1. The API layer. How fast your provider accepts requests. This is rarely what slows you down.
  2. The per-second carrier rate (TPS or MPS). How many segments per second the carriers will take from your registered campaign. It is counted per campaign, not per number and not per API key.
  3. The daily brand cap. T-Mobile limits how many messages your brand can send per day, based on your trust score. AT&T works differently: it throttles per second and per minute rather than setting a hard daily ceiling.

Ready's bulk endpoint takes up to 100 numbers per call. If a call is faster than your campaign's per-second carrier cap, it is refused with a retry_after_ms and nothing in that call is sent, so wait that long and send it again. An in-app campaign paces itself, so a long list does not need your own batching.

None of this is specific to Ready. Twilio, Telnyx, Plivo, Bandwidth and every other provider sending A2P 10DLC traffic sit on top of the same carrier rules. A provider can register you properly and route cleanly. No provider can sell you a way around the carrier's per-campaign rate. Anyone who claims they can is either sending unregistered traffic, which gets filtered, or describing something other than 10DLC.

The per-second rate: approximate figures

Carriers don't publish an official rate card, so treat every number here as a round approximation:

SituationApproximate per-second rate (segments/sec, per campaign)
Fresh standard campaign, no brand vettingAbout 1 to 4
Higher use-case tiersTens, roughly 10 to 75

Two details matter more than the exact figures.

It's segments, not messages. A segment is 160 GSM-7 characters, or 153 characters per part once a message splits. A single emoji switches the whole message to unicode, which drops the limit to 70 characters, or 67 per part. A 140-character text with one emoji is therefore 3 segments instead of 1. That emoji triples the time the message takes to drain and triples what it costs. (Ready swaps curly quotes, long dashes and ellipses for plain ones before sending, so pasting from a doc doesn't silently push you into unicode. Emoji still count.)

The use case sets the tier. The category your campaign is registered under shapes its throughput. If you registered as "marketing" but you actually send appointment reminders, you may be on the wrong tier. We cover that in why the right use-case category decides your throughput.

T-Mobile's daily cap and trust score

T-Mobile assigns your brand a daily message cap based on its trust score. Approximately, from lowest score to highest:

  • ~2,000 messages/day
  • ~10,000 messages/day
  • ~40,000 messages/day
  • ~100,000 messages/day
  • ~200,000 messages/day

The cap is per brand, which is the part that catches platforms off guard. If you registered three campaigns under one brand, they share a single T-Mobile daily allowance. Splitting traffic across campaigns doesn't create more room.

A low trust score doesn't mean you did anything wrong. New brands with no vetting often start near the bottom. If most of your contacts are on other carriers, you may never notice the cap. If a large share of your list is on T-Mobile, you'll hit it on day one of your first big campaign.

How brand vetting moves the daily cap (and what it doesn't move)

Brand vetting is an optional external review of your business that can raise your trust score. On Ready it costs $79 Standard or $179 Enhanced, one-time, on top of standard registration. Standard registration is $25/mo and $2 per number, and most approvals take 2 to 7 days.

What vetting does and doesn't do:

  • It can raise your trust score. That moves your T-Mobile daily cap only if the new score crosses into a higher tier. A bump that stays inside the same tier changes nothing you'll notice.
  • It does not change the per-second rate. If your problem is that a 50,000-contact send takes hours, vetting won't fix that. The per-second rate comes from your campaign and its use-case tier.
  • Most senders don't need it. If you send a few thousand messages a day, standard registration is enough. Vetting pays off for higher-volume senders who keep hitting the T-Mobile ceiling.

We wrote a full decision guide on whether 10DLC brand vetting is worth $79. The short version: work out your T-Mobile volume first, then decide.

A worked timing example (with stated assumptions)

This is an illustration, not a forecast. The assumptions:

  • 50,000 opted-in contacts
  • A 150-character message, all plain GSM-7 text
  • A fresh standard campaign at an assumed 3 segments per second
  • For comparison, a higher-tier campaign at an assumed 10 segments per second
  • An assumed 15,000 of those contacts on T-Mobile (your real share depends on your list)

Scenario A: plain text, 1 segment per message

  • Total segments: 50,000 × 1 = 50,000
  • At 3 segments/sec: 50,000 ÷ 3 ≈ 16,667 seconds ≈ 4.6 hours
  • At 10 segments/sec: 50,000 ÷ 10 = 5,000 seconds ≈ 1.4 hours

Scenario B: someone adds one emoji

The same 150 characters with an emoji becomes unicode. At 67 characters per part, that's 3 segments.

  • Total segments: 50,000 × 3 = 150,000
  • At 3 segments/sec: 150,000 ÷ 3 = 50,000 seconds ≈ 13.9 hours
  • At 10 segments/sec: 150,000 ÷ 10 = 15,000 seconds ≈ 4.2 hours

One emoji turned a send that finishes over lunch into one that runs overnight.

The T-Mobile layer on top

If your brand sits at the ~2,000/day tier, the 15,000 T-Mobile contacts take about 15,000 ÷ 2,000 = 7.5, so 8 days to reach everyone. At ~10,000/day it's 2 days. At ~40,000/day they all fit in one day, and only the per-second rate limits you.

Quiet hours stretch it further

On Ready, an in-app campaign that runs into the recipient's quiet hours waits up to 24 hours for the next window. An API text, including a bulk call, is held only if the window opens within 6 hours; otherwise it is refused with 409 QUIET_HOURS_BLOCK and your code must resend it. Either way a held text is charged only when it sends. If a 13.9-hour send starts in the afternoon, a large part of it will run into the evening, so expect those refusals overnight. That's deliberate: it reduces TCPA exposure. Plan for it, though, rather than treating it as a bug.

What the example costs

At Ready's Standard rate of $0.0075/segment plus a $0.0045 carrier fee per segment:

  • Scenario A: 50,000 × $0.0075, which is $1,000 plus 50,000 × $0.0045
  • Scenario B: 150,000 × $0.0075, which is $3,000 plus 150,000 × $0.0045

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.

Opted-out numbers, numbers on your Ban list and known landlines are refused up front and not charged. Full rates are on the pricing page.

What your code should do about it

You can't make carriers faster. You can stop your system from behaving as if a 200 means "delivered."

Send the list in batches of up to 100 per bulk request, not 50,000 single calls. On Ready that's POST /v1/messages/bulk:

curl -X POST https://api.tryready.com/v1/messages/bulk \
  -H "X-API-Key: $READY_API_KEY" \
  -H "Idempotency-Key: 6f1c2a9e-3b7d-4e21-9c4a-8d2f0b5e7a13" \
  -H "Content-Type: application/json" \
  -d '{"to": ["+12125550199", "+15559876543"], "body": "Your appointment is confirmed for Tuesday at 9 AM. Reply STOP to opt out.", "consent_attested": true}'

consent_attested is your promise that every recipient agreed to receive texts. The Idempotency-Key header means a timeout followed by a retry won't send the campaign twice. That matters most during long sends, where a client-side timeout is likely. See the docs for bulk messages and single messages.

Track progress from the message records, not the request. Page through GET /v1/messages with before_id to see what has actually gone out. Our SMS API integration walk-through covers the full request-to-delivery flow.

Treat segment count as a build-time check. Lint templates for emoji and length before they ship. A 161-character message is 2 segments and a 307-character message is 3, and each extra segment adds both send time and cost.

Schedule against the math, not the clock. If a campaign needs to land before a 9 AM deadline, work backwards from segments ÷ your assumed per-second rate, then add margin for quiet hours and the T-Mobile cap.

Don't try to multiply numbers to go faster. The per-second rate is per campaign. Adding ten numbers to the same campaign spreads the same throughput across more senders. Local presence works the same way: it picks among your registered numbers based on the contact's area code. It doesn't bypass registration or add capacity.

When to accept the limit and when to change something

An honest checklist:

  • The send takes hours but finishes the same day: this is normal for a standard campaign. Schedule earlier.
  • It runs into the evening and rolls over: start earlier, or cut segments (drop the emoji, tighten the copy).
  • T-Mobile contacts trickle in over several days: this is the daily brand cap. Check your trust tier, and consider vetting if a higher score would cross into the next tier.
  • Throughput looks low for what you send: check that your use-case category matches your traffic.
  • Messages are accepted but never arrive: that's probably filtering, not rate limiting. It's a content or registration problem, not a throughput one.

For a deeper look at the per-second ceiling specifically, see the TPS ceiling nobody mentions until you hit it.

FAQ

Why is my SMS campaign sending so slowly?

Carriers limit how many segments per second each registered 10DLC campaign can send, often only about 1 to 4 for a new standard campaign. Your API accepts the request instantly, but delivery drains at the carrier's pace. Long messages and emoji make it worse because they increase the segment count.

How many text messages can I send per second with 10DLC?

A fresh standard campaign without vetting typically gets about 1 to 4 segments per second, and higher use-case tiers get tens, roughly 10 to 75. Carriers don't publish an official rate card, so treat these as approximations. The limit applies per campaign, not per phone number.

Does brand vetting increase SMS throughput?

Brand vetting can raise your T-Mobile daily cap, but it does not change your per-second rate. The daily cap moves only if the higher trust score crosses into a new tier. On Ready, vetting costs $79 Standard or $179 Enhanced, one-time.

Can I send texts faster by adding more phone numbers?

No. Throughput is counted per campaign, so extra numbers on the same campaign share the same per-second rate. More numbers help with local presence and organization, not with speed.

Is there a daily limit on business text messages?

Yes. T-Mobile caps daily messages per brand by trust score, from roughly 2,000 a day at the lowest tier to roughly 200,000 at the highest. AT&T throttles per second and per minute instead of setting a hard daily cap.

The practical takeaway

The gap between "my code finished" and "my texts arrived" isn't a provider bug. It's carrier policy applied per campaign and per brand. Count segments, not messages. Plan schedules at an assumed per-second rate. Check your T-Mobile tier before a large send. Treat brand vetting as a fix for the daily cap, not the per-second rate.

If you want to see these numbers on your own traffic, you can sign up for Ready. Your first 20 one-to-one texts are free, so use them before you register. Registration is handled in-app, and the quickstart gets your first API send running.