Troubleshooting
Start with the pattern rather than the error text. Whether one message failed or all of them narrows the cause faster than any message the network returns.
First question: one, some, or all?
The panel will not let me send
Every refusal names the thing to fix.
- "Your DLT chain is not verified yet." Our telemarketer ID must be declared on your DLT portal, in order, and confirmed here. See Chain declaration. Nothing has been charged.
- "That template is not approved yet." It is still in review, or it was rejected. Check the Templates page for the reason.
- "The sender ID on that template is not approved yet." Same, on the Sender IDs page.
- "Your wallet balance is too low." Top up. The message was not sent and nothing was charged.
- "This template needs N variables and M were supplied." Count the
{"{#var#}"}markers in the approved body; you must supply exactly that many values, in order.
Messages send but never arrive
This is the pattern that matters most, because everything looks healthy.
Check the chain first
An under-declared chain accepts messages all the way to the operator and drops them there. If every message fails and the panel showed no error, this is the first thing to rule out.
Check the status, not just the send
A message at
senthas been handed over and not confirmed. Onlydeliveredis proof of arrival. See Delivery and status.Check the category against the recipient
Promotional messages are not delivered to numbers registered on DND, and only within the permitted daytime window. A test to your own number can fail for exactly this reason.
Check the delivered wording against the template
A variable over 30 characters, or one containing unexpected characters, produces text that no longer matches the approved template.
A message is stuck at pending
It has been submitted and no delivery report has come back yet. Most resolve in seconds; some take minutes.
If it is still pending much later, it will be settled automatically after 48 hours, and refunded if your account is charged on delivery.
Do not send it again. It has not been lost, and resending produces a second message that may well arrive alongside the first.
My bill is higher than I expected
Almost always parts rather than prices. Check the parts column on the Billing page against your message count.
- A message with a rupee sign is UCS-2 and fits 70 characters instead of 160. Writing prices is the usual cause.
- A message in Hindi or another Indian script is always UCS-2.
- A long variable value can push a message that normally fits one part into two, for some recipients and not others.
Message parts and encoding covers all of this.
An API call returns 401
- The key must be sent as
Authorization: Bearer sms_live_.... - Keys are shown once, at creation. If yours was not copied, revoke it and create another; it cannot be recovered.
- A revoked key returns 401 exactly like a wrong one, deliberately.
An API call returns 403
The endpoint needs a signed-in person rather than a key. API keys can send messages and read status, balance and pricing. Registering entities, sender IDs and templates, and creating other keys, are panel-only, because they are declarations made in your company's name.
Still stuck
Have this ready and support can usually answer in one reply rather than three:
- the message ID of a failed message, from the Messages page or the API
- what you expected, and what happened
- whether it is one, some or all
See Support.