How SMS route testing works
What a handset route test measures, what it cannot prove, how a sample report is built and how to read a failure.
A route test sends real content through a named route to named handsets in a named market on a date, then records what arrived and when. It proves that route on those handsets at that time. It does not prove every handset, every network or next week.
Key facts
- A route test proves a named route on named handsets in a market at a time.
- A test does not prove every handset, every network or future performance.
- A useful report carries the content, the handsets, the route, the receipt states and the date.
- A failure points to the route, the sender or the handset at that moment.
On this page
What a test proves
A route test answers a narrow question: if we send this content from this sender through this route to these handsets in this market today, what arrives and how long does it take? The answer is evidence for that combination. It is not a coverage claim, and it is not a forecast. A second handset, a second market or a route change can produce a different result.
That narrowness is the value. A test that names its handsets, its content and its date can be repeated and compared. A test that reports only a delivery percentage cannot. Ask for the raw record: the sender string shown on the handset, the receipt state, the time from submit to receipt and the reply path if the flow needs one.
Write the question down before the test. A question such as "does this route deliver an OTP from this sender to a common handset in this market within ten seconds?" produces a usable result. "Is the route good?" produces an opinion.
What the route test records
| Check | What the test records | What it does not prove |
|---|---|---|
| Delivery | Handset, market, sender, content and receipt state | That every handset in the market displays the message |
| Time | Submit to receipt, median and 95th percentile | The latency of every network or every hour |
| Sender | The string shown on the handset | That the string survives a route change |
| Reply | Reply path, reply time and content | That every inbound route works |
| Content | Exact template, encoding and segment count | That every filter accepts it |
| Repeat | The date and the conditions | What the route will do next month |
One handset per model is a sample, not a census.
How a test is run
Agree the question first. Is this a new route, a new sender, a new market or a change to an existing route? The question decides the handsets, the content and the number of sends. Then pick handsets that represent the market: more than one model, more than one network where the route crosses networks, and at least one handset on the network you expect to carry most of the traffic.
Freeze the content. Use the template you will send, including links, variables and the characters that decide GSM-7 or UCS-2. Send the same content to every handset, record the submit time, the receipt time and the state, and keep the raw data. If the flow needs replies, send a reply from each handset and record how long it takes to arrive. Run the test in the hour you expect traffic, not only in a quiet window.
The test sequence
-
Agree the question
Name the route, the sender and the market. Write down what a pass would look like.
-
Pick the handsets
Choose more than one model and, where relevant, more than one network. Record the model and the network.
-
Freeze the content
Use the exact template you will send. Record the encoding and the segment count.
-
Submit and record
Capture the submit time, the message ID and the route. Do not change the content between sends.
-
Read the receipt
Capture the state, the error code and the done time. A delivered state is not a display check.
-
Repeat on a second route
Run the same content on a second route if you need a comparison. Change one variable at a time.
-
Write the limits
State what the test did not cover: handsets, markets, hours, content and dates.
What a sample report contains
| Part | What it contains |
|---|---|
| Scope | The route, the sender, the market and the date |
| Method | How the handsets were chosen and how the content was frozen |
| Results | Delivery state, time to deliver and the sender string per handset |
| Replies | The reply path and the time, when the flow needs replies |
| Failures | The receipt state, the error code and the handset |
| Evidence | The raw records and the content used |
| Limits | What the test does not prove and when to repeat it |
A report without the content, the handsets or the date is a story.
Reading a failure
A missing receipt is not the same as a failed receipt. A missing receipt means the record never arrived; the message may still have reached the handset. A failed receipt carries a state and often a network code that names the reason: unknown subscriber, absent subscriber, memory full, barred service. Read the code before you change the route.
A delivered receipt with no display needs a different check: the handset, the messaging app, the spam folder and the sender string. A reply that never arrives points to the inbound route or the sender type, not to the outbound path. A slow result points to the route, a queue or a throttled bind. Fix the step the evidence names.
Record the failure with the same fields as a pass: handset, market, sender, content, route, time and state. A failure record without those fields cannot be compared with the next run, and the next run is where the fix is proved.
What to check before you trust a report
Ask for the date, the handsets, the networks and the exact content. Ask which route carried the traffic and whether it was direct or an aggregator. Ask for the receipt states and the error codes, not only a percentage. Ask what the test did not cover, and when it should be repeated.
Then compare the report with your own traffic. A test on one handset can pass while production fails on a different model, a different network or a longer template. The route test sample report shows the shape of the record. The provider guide turns the result into questions for the next supplier.
Check what you learned
-
A test delivers to one handset in Mexico City. What have you proved?
That this route, sender and content reached that handset in that market on that date. You have not proved other handsets, other networks or next week.
-
A receipt is missing. Is the message lost?
Not necessarily. The receipt record may be missing while the message arrived. Check the handset and the provider's record before you resend.
-
What would you repeat after a route change?
The same question, content and handsets on the new route, with a second route for comparison if the decision depends on it.
Answers are revealed on request. Nothing is scored, stored or sent.
FAQ
How many handsets does a test need?
Does a test prove deliverability?
How long does a test take?
Can a test compare two providers?
What if a test fails?
Terms you'll meet
Related
- Connecting over SMPP and HTTP
Take a test route to production without breaking binds, windows or receipts: bind, throughput, keep-alive, encoding, callbacks and failure handling.
- Global A2P sender-ID playbook
How sender IDs work across markets: alphanumeric, numeric and short-code paths, registration expectations and country examples.
- A2P SMS
Application-to-person SMS is traffic an application sends to a handset, such as a verification code or a transaction alert, via a registered sender.
Related products
Put this to work
Tell us the traffic, the destination and the measurement you need; we reply with the next step.