[NOWEB] - version 2025.9.x ~ 2025.11.1 Webhook payload.from sometimes contains @lid instead of a valid WhatsApp number — causing contact data corruption

[yusoft-app]

Summary
According to the webhook documentation at https://waha.devlike.pro/docs/how-to/events/#webhooks, the sample payload shows that payload.from contains a WhatsApp JID (e.g., 1234567890@c.us).
However, since around version 2025.9.x (and still present in 2025.11.1), many webhook payloads have payload.from values ending with @lid instead of a real WhatsApp number.
This causes serious issues because my backend app saves payload.from as the customer contact ID — and when it’s @lid, sending messages to that JID fails since it’s not a valid WhatsApp JID.

Please fix this so that payload.from always contains a valid WhatsApp JID (e.g., 62XXXXXXXXXX@c.us or 62XXXXXXXXXX@s.whatsapp.net), or alternatively, add a dedicated field like payload.remote_jid or payload.from_jid that always stores the canonical JID used for sending messages.

---

Impact

• My system automatically stores payload.from as the customer number. When it contains @lid, the app saves that as the contact, and sending future messages to it fails.
• To handle this inconsistency, I currently need to check multiple possible locations for the real number (_data.key.remoteJidAlt, _data.key.remoteJid, payload.id, etc.), which is messy and fragile.
• This leads to data pollution (contacts saved as @lid) and breaks automated message flows such as notifications or reminders.

---

Example Payloads (sanitized / dummy data)

❌ Problematic payload with @lid:

{
  "payload": {
    "id": "false_XXXXXXXXXXXX@lid_AC73A4448DFAC1A87C12DBA46E0C1A2C",
    "timestamp": 1762553488,
    "from": "XXXXXXXXXXXX@lid",
    "fromMe": false,
    "source": "app",
    "body": "Baik",
    "hasMedia": false,
    "media": null,
    "ack": 2,
    "ackName": "DEVICE",
    "_data": {
      "key": {
        "remoteJid": "XXXXXXXXXXXX@lid",
        "remoteJidAlt": "62XXXXXXXXXXX@s.whatsapp.net",
        "fromMe": false,
        "id": "AC73A4448DFAC1A87C12DBA46E0C1A2C",
        "addressingMode": "lid"
      },
      "pushName": "Oji R7"
    }
  },
  "engine": "NOWEB",
  "environment": {
    "version": "2025.11.1",
    "engine": "NOWEB",
    "tier": "PLUS"
  }
}

✅ Expected payload with valid WhatsApp JID:

{
  "payload": {
    "id": "true_XXXXXXXXXXXX@c.us_3EB05826BF9D924703E37E",
    "timestamp": 1762506635,
    "from": "XXXXXXXXXXXX@c.us",
    "fromMe": true,
    "source": "api",
    "body": "Hello ...",
    "_data": {
      "key": {
        "remoteJid": "62XXXXXXXXXXX@s.whatsapp.net",
        "fromMe": true
      }
    }
  }
}

Steps to Reproduce

1. Run WAHA (NOWEB engine) on version 2025.9.x or newer.
2. Observe incoming webhook payloads where payload.from sometimes has @lid.

Expected Behavior

1. payload.from should always contain a valid WhatsApp JID for the remote user (@c.us or @s.whatsapp.net).
2. If there’s a technical reason for returning @lid, please provide a canonical field (e.g., payload.canonical_from or payload.remote_jid) that always holds the actual JID that can be used for sending messages.
3. The documentation at https://waha.devlike.pro/docs/how-to/events/#webhooks should clarify:

• Whether @lid may appear in payload.from.
• Where the correct JID can be found for sending messages.
• Updated examples per engine (NOWEB, GOWS, WEBJS).

Environment Info

• WAHA Version: 2025.11.1 (NOWEB engine)
• First noticed: Around version 2025.9.x
• Impact: High (affects data integrity and automated messaging)

Temporary Workaround

I currently check multiple fields to find the real number:

• payload._data.key.remoteJidAlt
• payload._data.key.remoteJid
• payload.from
• payload.id

But this is unreliable and should not be necessary.

Request:

Please fix or clarify this behavior so that client systems can consistently extract the correct WhatsApp JID for contacts and messaging.

Thank you.

[OrionZap]

+1

[devlikepro]

Resolve it from lid to c.us using https://waha.devlike.pro/docs/how-to/contacts/#api---lids