Outbound messages to personal contacts via PN JID never delivered on LID-migrated account — @lid addressing works, @s.whatsapp.net silently fails

[agungpmbd]

Welcome!

• Yes, I have searched for similar issues on GitHub and found none.

What did you do?

On a WhatsApp account fully migrated to LID addressing (inbound messages arrive with
addressingMode: "lid", remoteJid: <id>@lid, remoteJidAlt: <phone>@s.whatsapp.net),
I sent outbound messages to personal contacts using the standard endpoint:
POST /message/sendText/{instance}
{"number": "62XXXXXXXXXX", "text": "test"}

To isolate the problem I systematically tested:

1. Multiple recipient numbers addressed by phone number (PN) — via API directly and via Chatwoot integration replies
2. The same recipient addressed as <lid>@lid — e.g. {"number": "1584XXXXXXXXXX@lid"}
3. Group messages (@g.us) — via API and Chatwoot
4. Three versions: v2.3.7 → 2.4.0-rc2 → homolog (all evoapicloud images), including builds containing fix fix(whatsapp): allow @lid contacts to bypass onWhatsApp validation #2544
5. Full session re-pair on homolog: logout, deleted the Session row from Postgres, fresh QR pairing — to rule out stale session state
6. POST /chat/whatsappNumbers on the affected numbers to look for a PN→LID resolution path

What did you expect?

Messages sent to {"number": "<phone>"} should be delivered to the recipient's device.
The send path should resolve PN → LID before dispatching (the mapping already exists
internally — OnWhatsappCache stores the lid, and inbound events carry both JIDs),
the same way the official WhatsApp client on the very same account does.

What did you observe instead of what you expected?

Path	v2.3.7	2.4.0-rc2	homolog	homolog + fresh session
Inbound (personal & group)	✅	✅	✅	✅
Outbound group (@g.us)	✅	✅	✅	✅
Outbound personal — PN (@s.whatsapp.net)	❌	❌	❌	❌
Outbound personal — @lid	✅	(not retested)	(not retested)	(not retested)

For the PN path: the API returns HTTP 201 with status: "PENDING", no errors in
logs (LOG_LEVEL=CLIENT,ERROR,INFO), the status never progresses past PENDING, and the
message never arrives on the recipient's device. Consistent across all recipient
numbers tested.

Sending to the exact same contact as <lid>@lid is delivered successfully.

POST /chat/whatsappNumbers returns exists: true for these undeliverable numbers and
does not include any lid field — so there is also no public API path to resolve
PN → LID as a workaround.

Impact: Chatwoot integration replies to personal contacts are 100% broken, since
Chatwoot always dispatches to the PN identifier. Replying from a LID-keyed conversation
works, which creates split-brain duplicate contacts (inbound lands on the PN contact,
outbound only works from the LID contact).

Screenshots/Videos

No response

Which version of the API are you using?

Reproduced on: 2.3.7, 2.4.0 (image tag 2.4.0-rc2), 2.4.0 (image tag homolog,
whatsappWebVersion 2.3000.1042742319)

What is your environment?

Windows

Other environment specifications

• Docker Compose (images: evoapicloud/evolution-api), Ubuntu 24.04 VPS
• Integration: Baileys (WHATSAPP-BAILEYS)
• Database: PostgreSQL 15 | Cache: Redis (alpine)
• Chatwoot integration enabled (Chatwoot installed natively on the same host)
• License activated (community tier) on 2.4.0 builds

If applicable, paste the log output

Send request response (PN path — accepted, never delivered):

{"key":{"remoteJid":"62XXXXXXXXXX@s.whatsapp.net","fromMe":true,"id":"3EB0..."},
"pushName":"Você","status":"PENDING","message":{"conversation":"test"},
"messageType":"conversation","source":"web"}

No ERROR entries appear in the container logs for these sends; the transaction is
treated as completed. Inbound event on the same account showing the LID pair:

"key": {
  "remoteJid": "1584XXXXXXXXXX@lid",
  "remoteJidAlt": "62XXXXXXXXXX@s.whatsapp.net",
  "fromMe": false,
  "addressingMode": "lid"
}

Additional Notes

• The official WhatsApp app logged into the same account sends to these contacts
  normally, so the account itself is healthy — this is a send-path addressing issue.
• Fix fix(whatsapp): allow @lid contacts to bypass onWhatsApp validation #2544 (bypass onWhatsApp validation for @lid) is confirmed present in the tested
  builds and unblocks sending to @lid JIDs, but does not add PN → LID resolution
  before sending — which appears to be the missing piece.
• Suggested fix: in the send path, consult OnWhatsappCache / contact store for a known
  lid mapping of the target PN and dispatch to the @lid JID when present. Exposing the
  lid in the /chat/whatsappNumbers response would also enable client-side workarounds.
• Happy to run diagnostic builds or provide further logs privately.

[agungpmbd]

lid_fix_v2.zip Man, I ran into the same headache with the LID migration issue. It looks like the outbound resolver was totally skipping the OnWhatsappCache lookup when hitting the PN endpoint. I put together a quick patch that forces the JID mapping during the dispatch phase so it actually hits the right target.

⚠️ Warning to others: do not download the zip above — unsolicited zip 'fixes' from new accounts are a known malware pattern on GitHub. Legitimate patches come as PRs or reviewable diffs.