What this issue is
A single, recurring symptom reported across several discussions, issues, and community reports. We're using this issue as the canonical place to collect reproducible cases and to track anything we can do on our side to soften it.
⚠️ This is partly outside OpenWA's control — see Why this happens below. Please read that section before assuming it's a code bug we can just fix.
The symptom
- You send a message through OpenWA to a phone number you've never messaged before (no prior conversation on either side).
- The OpenWA API returns success — you get a
messageId and a 200/201.
- But the message never arrives on the recipient's phone. Nothing in their chat with you.
- Existing conversations (numbers you've talked to before) work fine.
- Once the recipient messages you first — even once — sends to that number start working normally.
This has been reported with both engines (whatsapp-web.js and baileys), which is why we're tracking it in one place.
Why this happens (platform-side, not an OpenWA bug)
WhatsApp applies a server-side "reach-out" / trust policy to the very first message a number sends to someone it has never talked to. When that policy declines the send, it happens after the message has already left OpenWA — which is why the API honestly reports success: from the gateway's point of view, it did its job and handed the bytes to WhatsApp.
We cannot make WhatsApp's anti-abuse policy go away. No code change in OpenWA can reliably "fix" this for every reporter, because in many cases the decline is the correct outcome of that policy (e.g. fresh account + datacenter IP + bulk cold-send = exactly what the policy is designed to catch).
What we are doing about it
Even though the root cause is platform-side, there are a few things that genuinely reduce how often users hit this:
What we need from you (help wanted)
If you're hitting this and want to help us narrow it down, please post a runnable repro with the following, in this exact issue (don't open a new one unless a maintainer asks):
- OpenWA version: (output of `cat package.json | jq .version`, or image tag)
- Engine: whatsapp-web.js | baileys
- Hosting: home / VPS provider / k8s / cloud (please name it)
- IP type: residential | datacenter | mobile
- Account age: < 1 day | < 1 week | < 1 month | > 1 month
- Recipient: saved in your contacts? y/n ; has ever replied to you? y/n
- Volume just before: how many sends in the previous hour/day?
- Proxy configured? y/n ; if yes, what type
- Recipient phone OS: Android | iOS | KaiOS | unknown
Steps:
1. ...
2. ...
Actual:
- API returned: <paste the JSON response>
- Recipient saw: <nothing | message arrived after N minutes | arrived only after they replied>
Expected:
- Message arrives on the recipient's phone within seconds.
The single most useful piece of evidence: a cold-send that succeeds when run from a residential IP and fails from a datacenter IP (or vice versa). That isolates whether it's account-trust-driven or network-driven for your case.
What this issue is not
Related discussions
What this issue is
A single, recurring symptom reported across several discussions, issues, and community reports. We're using this issue as the canonical place to collect reproducible cases and to track anything we can do on our side to soften it.
The symptom
messageIdand a200/201.This has been reported with both engines (
whatsapp-web.jsandbaileys), which is why we're tracking it in one place.Why this happens (platform-side, not an OpenWA bug)
WhatsApp applies a server-side "reach-out" / trust policy to the very first message a number sends to someone it has never talked to. When that policy declines the send, it happens after the message has already left OpenWA — which is why the API honestly reports success: from the gateway's point of view, it did its job and handed the bytes to WhatsApp.
We cannot make WhatsApp's anti-abuse policy go away. No code change in OpenWA can reliably "fix" this for every reporter, because in many cases the decline is the correct outcome of that policy (e.g. fresh account + datacenter IP + bulk cold-send = exactly what the policy is designed to catch).
What we are doing about it
Even though the root cause is platform-side, there are a few things that genuinely reduce how often users hit this:
@whiskeysockets/baileys@7.0.0-rc13, which contains upstream work on first-contact reliability. Reports so far suggest it's better, not perfect.checkNumber/ "is this number on WhatsApp?" endpoint so callers can fail loud instead of getting a misleading success. Related: [Feature]: Number verification before send #522, Send endpoints report 201 success for recipients not on WhatsApp (no recipient pre-validation) #738.What we need from you (help wanted)
If you're hitting this and want to help us narrow it down, please post a runnable repro with the following, in this exact issue (don't open a new one unless a maintainer asks):
The single most useful piece of evidence: a cold-send that succeeds when run from a residential IP and fails from a datacenter IP (or vice versa). That isolates whether it's account-trust-driven or network-driven for your case.
What this issue is not
Related discussions