Sending an SMS is easy. Making sure it actually arrives — and knowing what to do when it does not — is the part that separates a hobby integration from a production messaging system. Mobile networks are distributed systems with many moving parts: aggregators, operator gateways, SMSCs, roaming partners and finally the handset itself. Any of them can fail temporarily. A good retry and fallback strategy assumes failure is normal and plans for it.
Start by understanding what "failed" actually means
Before writing retry code, make sure you know which stage failed. A single message passes through at least three checkpoints:
- API acceptance — your request reached the platform and was validated (credit, sender ID, template, recipient format).
- Submission to the operator — the message was handed off to the carrier network.
- Delivery receipt (DLR) — the network reports the final status: delivered, undelivered, expired, rejected.
An HTTP 200 from a send endpoint means the message was accepted, not delivered. Real delivery status arrives asynchronously, which is why webhook callbacks and delivery reports are the backbone of any retry logic. If you only look at the API response, you are blind to roughly everything that happens after submission.
Classify errors: permanent vs. temporary
Retrying a permanent error wastes credit and can harm your sender reputation. Retrying a temporary error is exactly the right move. Build a simple classification table in your code:
- Permanent (do not retry): invalid or non-existent number, number barred, unsupported destination, blacklisted recipient, content rejected by the operator, sender ID not allowed in that country.
- Temporary (retry is reasonable): handset switched off or out of coverage, memory full, network congestion, gateway timeout, temporary route failure, SMSC queue full.
- Ambiguous (retry once, then stop): "expired" or "unknown" statuses where the network never produced a definitive result.
Error codes differ between operators and providers, so map provider-specific codes into your own internal categories. That way your retry engine stays stable even if you change routes or add a second supplier later.
Design the retry schedule
Blind, immediate retries usually fail for the same reason the first attempt did. Use exponential backoff with jitter: for example attempt one immediately, the next after a short pause, then progressively longer gaps, with a small random offset so thousands of queued messages do not all fire at the same second.
Three practical rules:
- Cap the number of attempts. Two or three retries cover almost every recoverable case. Beyond that you are paying for messages nobody will read.
- Cap the total lifetime. Attach a validity window to each message. A marketing reminder may be useful for hours; a one-time password is worthless after a couple of minutes.
- Use idempotency keys. Send a unique reference with every request so a network timeout on your side does not produce two identical messages on the user's phone.
OTP traffic needs different rules
One-time passwords are a special case. The user is sitting on a verification screen, so latency matters more than persistence. Retrying the same code after five minutes is usually pointless — the session has expired and the user has already pressed "resend".
For OTP flows, prefer a fast single retry over a long retry chain, keep the code and its expiry consistent across attempts, and rate-limit resend requests per phone number to avoid both abuse and user confusion. Prioritised OTP routes and template-based sending, which UIPAPP offers for authentication traffic, reduce the number of failures you need to handle in the first place, but they do not remove the need for a fallback plan.
Fallback: changing the route or changing the channel
Retrying on the same path only helps with transient faults. When a route itself is degraded, you need a different path. There are two kinds of fallback:
- Route fallback — resend through an alternative route or provider for the same destination. Useful when one operator connection is congested or a particular country is misbehaving.
- Channel fallback — deliver the same information over a different medium. The most common escalation for critical notifications is a voice call: the message is read out to the recipient, and the call report shows who answered and for how long. UIPAPP supports this through its IVR voice calling feature, which is disabled by default and enabled per account by support, with country-based call pricing.
Channel fallback should be reserved for messages that genuinely matter: failed payments, appointment cancellations, security alerts. Escalating routine marketing content to a phone call annoys recipients and raises cost without benefit.
Instrument everything
A retry strategy you cannot measure is guesswork. Record, per country and per operator: submission success rate, final delivery rate, average time to DLR, retry success rate, and the distribution of error categories. Feed delivery webhooks into this dataset in real time rather than polling reports once a day. Patterns appear quickly — a single operator with a collapsing delivery rate, or a sender ID that started being rejected in one market.
A minimal checklist
- Validate and normalise numbers to E.164 before sending.
- Store a provider message ID and your own idempotency key for every send.
- Consume delivery webhooks and persist final statuses.
- Map error codes to permanent / temporary / ambiguous.
- Retry with backoff, jitter, an attempt cap and a validity window.
- Define which message types may escalate to another route or to a voice call.
- Suppress numbers that repeatedly return permanent errors.
- Monitor delivery rates by destination and alert on sudden drops.
Reliability in messaging is rarely about one perfect route; it is about how gracefully your system behaves when a route underperforms. Get the classification and the timing right, and most delivery problems resolve themselves before your users ever notice them.