Messages are accepted but not arriving
Every call returns success. Work through this in order — the first four checks do not involve the carrier at all.
Read this article →A recipient received the same message twice
Almost always this is a client-side timeout followed by a resend. Here is how to confirm it, and how to stop it happening.
Confirm it was a resend
Two sends with the same recipient and nearly identical timestamps, both accepted, is the signature of a retry. There is no idempotency key, so the platform has no way to treat the second request as the same message — it is a new message, sent and billed.
Filter the log by recipient
Set the time window around the incident and add the number.
Compare the timestamps
Seconds apart means a resend. Far apart means two separate requests from your side.
Check both messageIds
Two distinct platform IDs with two provider IDs confirms two independent sends.
Prevent it
- Treat a client-side timeout as unknown, not as failure — the message may already be on its way.
- If a request times out, look it up in the log by time window and recipient instead of resending.
- De-duplicate on your side before calling the API: record that you intended to send, then reconcile against the log.
Note. Duplicate prevention has to live in the caller. The platform deliberately offers no idempotency key, so a retry is never silently swallowed.
Keep reading
Messages that fail with an error code
A failed status always carries a reason. The first question is which layer wrote it — the platform or the provider.
Read this article →A provider stopped accepting traffic
Telling an account-level failure apart from a bad route, and what failover can and cannot absorb for you.
Read this article →