Published: November 21, 2022
Your SMS Messages Are Likely Being Capped by Your Messaging API Provider (and Why You Should Care)
Written by Aaron Alter
The idea that the majority of messaging API providers are widely capping, or limiting, their customers’ A2P SMS and MMS messaging campaigns is pretty wild. Especially for senders who have either verified their Toll-Free messaging traffic or registered their 10DLC (10-digit long code or local numbers) messaging traffic so that they could secure higher and use case-appropriate throughput limits! But capping is a reality, and we’ll explain why.
“Throughput” refers to the number of messages you are sending within a specific period of time. A “throughput limit” refers to the number of messages you are able to send within a specific period of time, based on the below factors:
- Whether or not you’ve verified your Toll-Free messaging traffic or registered your 10-digit long code (10DLC) messaging traffic. If you haven’t verified or registered, which is mandatory, you are sending messages from the Person-to-Person (P2P) pathway, instead of Application-to-Person (A2P). The P2P pathway is designated for everyday interactions between people – the throughput limit for P2P messaging is 60 messages per minute. This is plenty sufficient for the use case, but is extremely limiting for business, or A2P, use cases.
- Which Carrier, or Mobile Network Operator (MNO), your end user (or message recipient) is using. Verizon is monitoring throughput by messages sent per second; AT&T by messages sent per minute. T-Mobile, on the other hand, has a daily cap, monitoring messages sent per day.
Throughput limits were established to both prevent the MNOs’ systems from being overwhelmed or bottlenecked, and protect the end user from unsolicited messages and/or SPAM.
By verifying your Toll-Free messaging traffic and registering (with The Campaign Registry) A2P 10DLC messaging traffic, you’re providing the MNOs with information they need to validate your A2P messaging use case and throughput needs, rewarding you with the highest throughput limit deemed required for your use case.
When messages are being “capped”, it means that they are being sent to the MNOs at the lowest speed of all your Campaigns. This approach to avoiding exceeding throughput limits can work if you have a single Brand (your customer) and a single Campaign (their messaging use case) to send to at a time. The problem is that the majority of SaaS businesses offering SMS and MMS messaging to their customers have many – hundreds to thousands –Brands and Campaigns.
When an API provider caps, they’re doing it across the board for your Brands and Campaigns. If you have one Campaign approved to send 60 messages per minute on AT&T, and another Campaign approved to send 4,500 messages per minute on AT&T, all of your Brands’ Campaigns will be capped at the lowest amount, aka 60 messages per minute, so that none of them will exceed the lowest throughput limit.
Messages are therefore delivered with unwanted delays, regardless of the sender’s use case (which can range anywhere from a Black Friday marketing blast to two-way communication with customer care to an emergency notification).
Because of their per second and per minute throughput limits, capping can only be done for AT&T and Verizon recipients. In the graphic below, you can see that regardless of the throughput limit that the sender has been rewarded through verifying their Toll-Free messages or registering their 10DLC messages, those messages are being throttled at low speeds by the messaging API provider. Between the time and money invested in verifying and/or registering your traffic, plus the expectation that you’re sending at your approved throughput limits, capping is extremely misleading and damaging to your overall messaging ROI.
T-Mobile’s daily cap complicates API providers’ capping approach to managing throughput. Because T-Mobile limits throughput per day, these providers simply lift the ceiling and send messages all at once since they don’t have another reliable way to throttle other than capping. Depending on how many Campaign recipients are T-Mobile users and what your approved throughput limit was for said Campaign, lifting the ceiling could result in messages being dropped or blocked altogether.
To verify this for yourself, you can actually look at your current provider’s website and search “exceeding T-Mobile daily limits” or error codes. Twilio shows a 30023 error code for 10DLC messages, Bandwidth a 4780 error code (and a 4781 for AT&T) for 10DLC messages, and so on. If your messaging API provider, such as Twilio or Bandwidth, got your A2P 10DLC traffic registered and therefore approved for higher throughputs, but preemptively created error codes for exceeding those limits despite being responsible for managing them, how can you scale your messaging business, volume, and ROI safely?
We admit that accurately and effectively managing throughput limits is complex, but it’s also imperative and can only be managed on the API provider’s side. Upon founding Telgorithm, our team developed what we call smart queueing technology which enables us to automatically lookup and track what sending limits our customers have been approved for, who each message recipient’s MNO is, and how many messages are being sent to this particular MNO at this particular time. The tech then queues up the messages accordingly, supporting maximum send rates at the exact approved throughput limit, without dropping messages or risking blockages. Telgorithm is the only vendor today to offer this tech and process – it is currently patent-pending.
If you’re interested in learning more or want to know how your business is being affected, schedule a consultation with one of our SMS experts today.
Subscribe to our newsletter.
Navigate the cloud communications world with knowledge. Subscribe to our blog newsletter to receive the latest industry news, tips, and guidance.
By clicking the submit button below, I hereby agree to and accept Telgorithm’s terms and conditions.