Accepted
The request entered processing; delivery is not confirmed.
Message status and DLR reporting
SMS delivery reports and message status
Track Accepted, Sent, Delivered, and Failed states, and connect DLRs or webhooks to your system to handle each message outcome.
Delivered
An available delivery state was returned.
Failed
A permanent or temporary reason needs classification.
Reading the report
The difference between request acceptance and delivery
A send request moves through several states. It may first show Accepted, then Sent, followed by Delivered or Failed. We store the message ID against the order or customer so the final status remains in context.
Failure reasons are classified as temporary and eligible for a controlled retry, or permanent, such as an invalid number. This helps clean lists and avoid attempts that cannot succeed.
Implementation steps
How we prepare and launch the service
We review the use case and requirements, then test the setup before production sending begins.
- 01Store the message ID
Correlate it with the business record.
- 02Receive status
Webhook or report, depending on setup.
- 03Classify the reason
Temporary, permanent, or review-needed.
- 04Improve the flow
Number hygiene and retry policy.
Information we need
Share these details for an accurate proposal
These details help us confirm pricing, requirements, and the right operating model from the first conversation.
- 01Current sending method
- 02Systems that need status
- 03Retry policy
- 04Report retention needs
Frequently asked questions
Straight answers about the service
Does delivered mean the customer read the message?+
No. It is an available network or handset delivery state, not a user read receipt.
Do all countries return identical statuses?+
No. Detail level and timing can vary. We clarify what is available for the selected route and destination.
Should every failed message be retried?+
No. Only temporary failures should be retried under a limited policy. Permanent failures must not enter a resend loop.
Related services