A2P SMS Rate Limits by Destination: How to Agree and Manage Them
A stated TPS limit does not guarantee delivery. Learn how to clarify its scope, manage destination-specific queues, and assess operational signals without confusing acceptance with delivery.
A stated TPS limit is not a delivery guarantee
TPS is commonly used to mean messages per second, but an advertised figure is useful operationally only when you know what it measures, where it applies, and under what conditions. There is no universal limit that can be inferred from a country, operator, or connection type alone: confirm it with the party managing the route and document its scope.
You also need to distinguish the stages of sending. An acceptance response confirms, at most, that a request was admitted at that point in the chain; it does not, by itself, prove that the SMS reached the phone. Interpret later statuses, including DLRs, according to their source and level of verification.
- Treat a stated TPS as a condition to clarify, not as a general delivery promise.
- Track request admission and later message statuses separately.
- Do not extrapolate a route’s figure to other destinations, operators, or senders.
What to clarify before configuring traffic
Ask for a written definition of the limit’s scope and how it is measured. Clarify whether it applies to a country, an operator, a route, a sender, an account, or a session. Also ask whether it varies by traffic type, such as OTP, transactional, or legitimate marketing traffic, and what measurement window is used.
The connection does not replace this agreement. SMPP defines aspects of the exchange between an application and an SMSC, while HTTP describes the semantics of requests and responses; neither specification, by itself, sets a guaranteed TPS for an A2P route or confirms mobile delivery.
- Destination and applicable operator or operator group.
- Route, account, sender, and included traffic type.
- Unit, measurement window, and treatment of rejected requests.
- Per-session limit and aggregate limit, if both exist.
- Conditions for bursts, concurrency, pauses, and capacity changes.
- Response codes and operational contact for incidents or adjustments.
Distinguish sustained rate, bursts, and concurrency
Do not assume that a nominal rate means you can send that volume continuously. Ask the provider to define whether the figure is sustained, an instantaneous maximum, or an average over a specified window. If bursts are allowed, ask about their conditions and duration; if sessions or simultaneous requests are limited, record those limits separately.
The available evidence does not support recommending universal values for these parameters. If the provider cannot define them, mark the condition as unconfirmed and avoid designing the system around an optimistic interpretation.
- Document each parameter separately; do not reduce all limits to a single TPS figure.
- Distinguish message rate, number of simultaneous requests, and connection sessions.
- Note whether the limit is shared across destinations, senders, or connections, or whether the provider has not yet clarified this.
Design admission controls and destination-specific queues
Organize traffic into queues that match the actual scope of each limit. If a provider confirms different limits by operator or route, avoid letting a global queue hide an excess in one of those groups. Before putting the control into production, verify how the destination is identified and what happens to messages whose routing has not yet been resolved.
The outbound rate should be adjustable without silently discarding messages. Define what remains queued, what is retried, and how retries are prevented from amplifying congestion. The specific criteria depend on the agreement and observed behavior; without that information, no universal configuration can be recommended.
- Associate each queue with a confirmed limit and preserve that relationship in the configuration.
- Set an explicit rule for pausing, resuming, and retrying after rejections.
- Record rate and configuration changes so they can be compared with outcomes.
- Ensure traffic priorities do not override destination restrictions.
Read operational signals in context
An increase in rejections or in the latency of an acceptance response may indicate that a restriction is being reached, but it does not, by itself, identify the cause. Check whether it coincides with a change in volume, route, session, or configuration, and ask the provider to interpret the response codes. Do not automatically attribute the issue to a TPS limit.
Also monitor queue depth and age, accepted versus rejected requests, and available later statuses. Admission latency and DLRs describe different stages; a received DLR should not be presented as independent verification that a message reached the phone unless that verification exists.
- Rejections: count by code, destination, route, and time period.
- Latency: separate API or session response time from later statuses.
- Queues: monitor depth, age, and drain rate.
- Statuses: distinguish acceptance, DLR, and any genuinely verifiable receipt confirmation.
Test gradually and with consent
Before a test, agree with the provider on the destination, sender, traffic type, time window, starting rate, and stop conditions. Use only legitimate messages and recipients who have consented to the traffic, in compliance with applicable rules. Do not increase load on real destinations without explicit authorization.
Increase volume in a controlled manner, record each change, and stop the test if agreed error or congestion signals appear. A test demonstrates observed behavior under those conditions; it does not turn the result into guaranteed production capacity or evidence applicable to other routes or periods.
- Agree on the scope and stop criteria in advance.
- Keep variables you are not evaluating constant and document any changes.
- Do not use an unauthorized test as a substitute for contractual confirmation.
Respond to possible congestion
If rejections, latency, or queue depth increase persistently, reduce the admission rate and follow the agreed procedure. If conditions continue to deteriorate, pause the affected traffic where appropriate and contact the provider with specific data. Do not automatically increase concurrency or accelerate retries: without knowing the route’s rules, those actions may increase pressure or make diagnosis harder.
Keep an incident timeline: time, destination, route, volume, configuration changes, received codes, and queue progression. Ask the provider to confirm whether a limit was reached, whether a different operational condition occurred, or whether the current limit changed. Escalate through the agreed channels and record the response.
- Reduce the affected rate and avoid aggressive retries that have not been agreed.
- Provide error codes and metrics segmented by destination and route.
- Request an operational decision and written confirmation of any limit change.
- Resume gradually in line with the agreed procedure.
Review limits and preserve evidence
Maintain a versioned record that distinguishes provider-stated conditions from what is observed in production. Include the confirmation date, scope, parameters, exceptions, and the person responsible for validating any change. If metrics differ from what was agreed, request a review; do not replace a contractual limit with a maximum observed in a brief test.
Review the record when the route, destination, sender, session, or traffic pattern changes, and after significant incidents. BulkSMSMarket is building an enterprise platform to discover, compare, buy, sell, and manage A2P SMS capacity; its public numerical cards are illustrative until contractual route data is connected. They should therefore not be treated as active commercial limits.
- Keep the stated limit, applied configuration, and observed evidence separate.
- Record the period and conditions of each test or incident.
- Review the provider agreement before changing operational capacity.
Frequently asked questions
Is there a universal TPS limit for A2P SMS by country?
The available information does not support establishing a universal figure. Confirm the limit with the party managing the route and document which destination, operator, sender, session, and measurement window it applies to.
Does acceptance of a request mean the SMS was delivered?
No. Acceptance indicates that the request was admitted at one point in the process, but it does not, by itself, prove delivery to the phone. Interpret later statuses separately and consider the level of verification they provide.
Do SMPP or HTTP set a route’s guaranteed rate?
Not according to the available evidence. SMPP and HTTP specify aspects of technical exchange, but their specifications do not, by themselves, establish guaranteed A2P capacity by destination.
What should I do if burst or concurrency limits are undefined?
Ask for a written definition and record those parameters as unconfirmed until you receive one. Do not infer their values from the nominal TPS or a single test.
Does a successful test prove sustainable production capacity?
Not necessarily. It describes only the behavior observed under the conditions of that test. The result does not guarantee future capacity and cannot automatically be extrapolated to other destinations, routes, or periods.
Sources consulted
- SMPP Protocol Specification v3.4SMPP Developers Forum
- HTTP Semantics (RFC 9110)Internet Engineering Task Force
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA networks resourcesGSMA