WhatsApp Guides
WhatsApp API Message Sent but Not Delivered? How to Find the Failure
A successful send request and a delivered message are different events. Follow one message through the process before retrying or changing your setup.
The CRM says “sent.” The customer says nothing arrived. Your first instinct may be to press send again.
Pause long enough to trace the original message. A successful request, a provider message identifier and a delivery status answer different questions. Repeated sends can create duplicates without fixing the underlying problem.
Find out what “sent” means in your system
Ask your provider how its interface maps delivery events. A status may mean the application queued the job, the provider accepted it or a later platform event was received. Those stages should not be treated as interchangeable.
Follow one message using its identifier and timestamps. If your interface does not expose that information, ask the authorized support team to retrieve it. Avoid diagnosing from a screenshot of a single status label alone.
Locate the point where progress stopped
| What you observe | Next question |
|---|---|
| Still queued | Did the application actually attempt the send? |
| Request rejected | What exact error did the provider return? |
| Accepted, later failed | What does the final failure event say? |
| Accepted, no later status | Was a delivery event received and processed? |
| Delivered, not read | Are you confusing delivery with a read indication? |
Do not conclude that a missing read indication proves a delivery failure. Equally, acceptance by an API is not proof that the recipient received the message.
Inspect the exact error before choosing a fix
Copy the error code and description into the support record, along with the time and message reference. Use Meta’s current WhatsApp error-code reference and your provider’s documentation to interpret the actual result.
Broadly, the investigation may involve the recipient address, the allowed sending method, a template issue, account restrictions, platform limits or a temporary service failure. These categories are a triage guide, not a substitute for the returned error.
Do not change the recipient number, template or account configuration at random. Make one evidence-based correction and keep a record of what changed.
Check templates and conversation timing
If the message was part of a scheduled follow-up, confirm which template and language were selected and whether the required values were supplied correctly. A template that was available when the sequence was built may need attention later.
Check the latest customer interaction and the sending route. The 24-hour follow-up guide explains why an old free-form response cannot simply be reused as a scheduled Platform message outside the service window.
Separate delivery from status reporting
Sometimes the issue lies in the status path rather than the message path. The provider may have a later event that the CRM has not yet processed or displayed. Ask the integration owner to compare the provider record with the application record for the same message identifier.
Use a consenting test recipient for a controlled check if needed. A successful test to one person does not prove that every recipient or message type will work, but it can help narrow the scope.
Retry only when the cause supports it
A temporary failure may have a documented retry approach. An invalid address or a rejected template generally requires a correction first. Restrictions and quality-related errors should be handled according to the provider’s current guidance, not by repeatedly resending or switching numbers to work around the restriction.
Before a retry, check whether the original message eventually succeeded and whether the customer’s situation has changed. An outdated quotation reminder is still outdated even after you fix its delivery problem.
Give support a useful evidence bundle
- Approximate occurrence time with timezone.
- Internal message reference and provider message identifier, if available.
- Exact status sequence and error description.
- Template name and language, where relevant.
- Whether the issue affects one recipient or a wider set.
- Recent configuration changes and any controlled test result.
Share this through the provider’s authorized support route. Redact customer details from public screenshots and never include access tokens in a public forum.
For SHVYA, provide the support team enough context to identify the affected conversation securely. If several employees are retrying independently, first assign one incident owner using the shared inbox responsibility rules. One well-traced message is a better starting point than ten unexplained retries.
