Message Retry resends a failed message on a different connect, based on the error code returned by the first connect. It recovers messages automatically while traffic is flowing, before anyone has to repush manually.
With the Routes Multiple Retry plugin (paid), a route can retry up to 4 times, each time on a different set of connects.
Where to find it
Sidebar → SMPP Client → Routes → Add or Edit a route → Message Retry section.
Fields
| Field | What it does |
|---|---|
| Message Retry | Enables retry for the route |
| Number of Retries | How many retry levels to use (up to 4 with Routes Multiple Retry) |
| Retry Error Codes | The global error codes that trigger a retry. Only these failures are retried |
| Retry Connects 1–4 | The connects used at each retry level |
A message is retried only once per retry level, on one of the connects selected for that level.
How to pick retry error codes
Retry only failures that a different vendor has a real chance of delivering:
Good retry candidates
- Vendor/route-side failures: throttling, system errors, submission timeouts, “route not available”
- Vendor-specific template or sender ID rejections, when the retry connect has that template or sender ID registered
Don’t retry
- Invalid or non-existent numbers
- Numbers on DND/NCPR (for promotional traffic)
- Content blocked for policy or spam reasons
- Absent subscriber / handset off. Another vendor will get the same result, and you pay twice.
This is why well-designed Global Error Codes matter: retry decisions depend on them.
Example setup: India transactional
- Primary: Vendor A (Round Robin across 2 connects)
- Retry Error Codes: vendor system error, throttled, template mismatch at vendor
- Retry Connects 1: Vendor B
- Retry Connects 2: Vendor C
Costs and billing
Every retry is a new submission to a vendor. If your retry connects bill on submit, a failed first attempt plus a retry can cost you twice for one client message. Watch margins in your billing and usage reports for the first few days after enabling retry, and keep retry lists short on connects that bill on submit.
Retry vs Repush vs Multi-Channel Fallback
| Tool | When it runs | Use it for |
|---|---|---|
| Message Retry | Automatically, on each failure | Ongoing vendor-level failures |
| Repush Messages | Manually, after an incident | Bulk recovery after an outage |
| Multi-Channel Fallback | Automatically, across channels | Moving to WhatsApp/RCS when SMS fails |
Troubleshooting
- Failed messages aren’t being retried: check that the failure’s global error code is in Retry Error Codes, and that the vendor’s raw code is mapped to it (unmapped codes can’t match).
- Retry fails on the same error: the retry connect has the same limitation (template, sender ID, destination). Pick a connect that actually differs.
Related articles
- How to Set Up Global Error Codes
- How to Repush Failed Messages Through a Different Route
- How to Create a Route and Choose a Distribution Strategy
- Do the Failed Messages Get Retried in SMPP Client?