Repository navigation
[META] @lid vs @jid handling — tracking umbrella #1872
Description
Activity
same here
same here
same here
I was looking and practiced with docker, and I think that is necessary update evoapi to 2.3.* 'cause these versions add news field (remoteJid, senderLid)
But, Idk how convert a @lid to Jid to previous versions
same here,
upgrading to version 2.3.x solves the problem and would shows the number?
same here,
upgrading to version 2.3.x solves the problem and would shows the number?
It doesn't solve the problem... I'm on version 2.3.0 and sometimes @lid still appears in remotejid, and it's not possible to use this lid for anything (In version 2.3.1 latest, it doesn't send messages on mobile devices #1789)
I'm experiencing exactly the same thing. The question is whether or not it sends the message, because my clients haven't said anything to me.
Does anyone know the solution?I come across this other issue and comment in Baileys: WhiskeySockets/Baileys#1692
Wondering if it's related and if there is some path forward with this proposed solution.
@Simplobot1 The issue you mentioned with Evolution API and the remoteJid format in the webhook (receiving "@lid" instead of "@s.whatsapp.net") is a recent bug on the platform and affects normal functioning of workflows and automations, since many bots and systems expect the traditional WhatsApp JID.
Cause and Context
- WhatsApp is changing the identifier for certain users and contacts, sending some events with the "@lid" suffix instead of the older "@s.whatsapp.net", especially for new, unauthenticated users or due to privacy/security measures.
- This affects automation logic, since many flows require the classic format to filter messages, execute conditions, or reply.
Possible Solutions and Workarounds
- In some flows, it is possible to extract the actual phone number from the "senderPn" field when a JID with "@lid" is received, and manually construct the string with "@s.whatsapp.net".
- In critical cases, it's recommended to ask the user to add the bot as a contact to "consolidate" the JID as @s.whatsapp.net.
- For now, there is no direct fix from Evolution API, although it has been reported as a bug on GitHub and other users are facing the same issue, awaiting an official solution.[9][11]
- Temporary recommendation: Implement a function in your webhook that converts @lid to @s.whatsapp.net using the phone number in the senderPn field if available.
Example Code Adaptation
// Suppose message is your webhook payload let remoteJid = message.key.remoteJid; if (remoteJid.endsWith('@lid')) { if (message.key.senderPn) { remoteJid = `${message.key.senderPn}@s.whatsapp.net`; } else { // Handle error or block flow return; } } // Continue your workflow normally...
This is a temporary solution. Honestly, I haven’t had the time to implement it, but if someone here does and it works or can improve it, I would appreciate it if you could share your solution with us.
Como não sabemos por onde possa vir, estou filtrando e tentando identificar por onde vem o número. Criar um nó para tratar isso.
`{{(() => {
const remote = $json.body?.data?.key?.remoteJid || "";
const sender = $json.body?.data?.key?.senderPn || "";// Se remoteJid termina com @s.whatsapp.net, extrai número
const matchRemote = remote.match(/^55\d{10,12}(?=@s.whatsapp.net$)/);
if (matchRemote) return matchRemote[0];// Caso contrário, tenta com senderPn
const matchSender = sender.match(/^55\d{10,12}(?=@s.whatsapp.net$)/);
if (matchSender) return matchSender[0];return "indefinido";
})()}}
`There is a new release for Baileys: https://github.com/WhiskeySockets/Baileys/releases/tag/v6.7.19 and solidified LID support will be released by end of this week (Sept 7) as v6.8.0.
Has some tried updating?
Same here, is there anyway to try baileys update fron docker compose?
@tomatoes-prog release v2.3.2 already updated Baileys to 6.7.19
Same problem, any solutions, please? I have atendai/evolution-api:2.2.3
Same problem here (V.2.3.3 - latest). It works fine with IOS. With Android still have the @lid issue!
Replacing phone@lid for phone@s.whatsapp.net didn´t work for me!10 remaining items
- marked [BUG] Erro 400 "exists: false" ao responder JID com sufixo @lid via HTTP Request #2433 as a duplicate of this issue
on Apr 22, 2026 - marked Estou recebendo @lid no lugar de contactID como ajustar isso? #2387 as a duplicate of this issue
on Apr 22, 2026 - marked Webhook messages started arriving today with @lid only (no phone number), breaking replies in Evolution API + n8n #2326 as a duplicate of this issue
on Apr 22, 2026 - marked No está funcionando la solución al bug de remotejid = @lid #2324 as a duplicate of this issue
on Apr 22, 2026 - marked Typebot integration sends lid and not jid #2251 as a duplicate of this issue
on Apr 22, 2026 - marked [Bug] Typebot fails to send messages to users with LID - BadRequestException jidOptions.exists false #2132 as a duplicate of this issue
on Apr 22, 2026 - marked [BUG] Chat table not creating new entries since late September 2025 - @lid format contacts affected #2051 as a duplicate of this issue
on Apr 22, 2026 - added a commit that references this issue
on Apr 28, 2026 Sharing a workaround for the Chatwoot duplicate contacts symptom mentioned in this thread, in case it helps others self-hosting Evolution API + Chatwoot who are stuck on v2.3.7 (or any version where @lid → phone JID mapping isn't fully resolved yet).
Context: running Evolution API v2.3.7 with Chatwoot v4.16.1 via Channel::Api. When a contact enables the WhatsApp @username feature, their remoteJid switches from NNNNNNNNNN@s.whatsapp.net to an opaque NNNNNNNNNN@lid, and remoteJidAlt frequently arrives empty — so there's no way to resolve back to the phone number from the payload alone. This caused two problems downstream in Chatwoot:
Duplicate contacts — existing customers with prior conversation history under their phone-number identifier would get a second, brand-new contact created under the @lid identifier, splitting their history into two separate threads.
Media not delivered — for @lid messages, only a text placeholder made it through to Chatwoot; actual audio/image/video/document attachments never arrived.What fixed it for us (middleware, not a fix to Evolution API itself):
We put a small n8n workflow between Evolution's webhook and Chatwoot's API that:
Intercepts MESSAGES_UPSERT events where addressingMode === "lid" and remoteJidAlt is empty
Looks up the contact in Chatwoot by identifier = remoteJid first (covers @lid we've already seen)
If not found, searches Chatwoot contacts by exact pushName match, filtered to contacts that already have a real @s.whatsapp.net identifier
Exactly one match → treat that contact as the correct one going forward (safe — no name ambiguity)
Zero or multiple matches → create a new contact as before, and fire an alert (we use Telegram) for a human to review and merge manually. This avoids false-positive merges when several contacts share a common name.
For media messages, calls POST /chat/getBase64FromMediaMessage/{instance} with the message key, converts the returned base64 to binary, and re-uploads it to Chatwoot as a proper multipart/form-data attachment via POST /conversations/{id}/messages — instead of relying on the webhook payload to carry the media directly (it doesn't, for @lid messages, at least on v2.3.7).This obviously isn't a substitute for a real Baileys-level @lid → @s.whatsapp.net mapping, which is the right long-term fix and what this thread is tracking. But it's been stable in production for us, and since Chatwoot is one of the most common integrations people mentioned hitting this with, I'm happy to share the n8n workflow JSON (sanitized) if anyone building on Chatwoot wants a starting point — just let me know here.
- added a commit that references this issue
on Aug 31, 2026 Evolution API version: v2.3.7 (Docker: evoapicloud/evolution-api:latest)
Integration: Chatwoot
Related to: #1872, #2324What happened
Messages (both text and reactions) from a specific WhatsApp contact never reach Chatwoot. No conversation is created, and no error is shown to the end user — the messages are silently dropped from Chatwoot's perspective.
The contact's
remoteJidarrives in@lidformat, butremoteJidAltis completely absent from the payload (not just empty — the key doesn't exist at all). Since the Chatwoot integration relies onremoteJidAltto resolve the real phone number (per the fixes in #2249 / #2275), it has no fallback when this field is missing entirely.Logs
Message reception (note: no
remoteJidAltfield anywhere in the key):{ "key": { "remoteJid": "207678898962522@lid", "fromMe": false, "id": "3EB05E2A71E71B3A51049F", "participant": "", "addressingMode": "lid" }, "pushName": "aaaa ddddd", "status": "DELIVERY_ACK" }Resulting Chatwoot service error:
I ran into this exact issue — a contact whose messages arrived with
addressingMode: 'lid'butremoteJidAltcompletely missing (not just
empty, absent from the key). This causedcreateConversationto crash
withTypeError: Cannot read properties of undefined (reading 'split'),
resulting in 100% message loss (text + reactions) for that contact in
the Chatwoot integration.Opened a fix here: #2718
It falls back to the LID itself when
remoteJidAltis absent, so the
conversation still gets created (contact shows up identified by LID
instead of phone number) instead of crashing silently.- added a commit that references this issue
on Oct 8, 2026
Background
WhatsApp is rolling out
@lid(Linked ID) identifiers for some users — it replaces the classical phone-number-based@s.whatsapp.netJID in certain events. Evolution API (and Baileys) currently doesn't fully translate@lid→ phone JID in all code paths, which breaks automations, integrations and lookups.Known symptoms
Webhook / event payload
remoteJidarrives asNNNNNNNNNN@lidinstead of phone-based JID, breaking downstream automations (n8n, Typebot, Chatwoot)messages.upsert/messages.updateevents started arriving with@lidonly, no phone number@lidintermittently for the same contactAPI endpoints / database
GET /chat/findContactsreturns stale@lididentifiers after WhatsApp META update@lidJID via HTTP Request returns400 "exists: false"Unknown argument "lid". Did you mean "id"?when sending messagesChattable stops creating new entries for@lidcontacts (since late Sep 2025)Integrations
@lidinstead of JID, resulting inBadRequestException jidOptions.exists false@lid, one with phone JID); historical import fails for@lidconversations (syncFullHistory=truehas no effect)@lidGroup events
@lidinstead of JID of the leaving memberStatus
Ongoing — requires Baileys-level mapping of
@lid→@s.whatsapp.net. Partial fixes have landed in various versions but the community reports symptoms persist on v2.3.7.For maintainers
All duplicate
@lidissues are being closed withstate_reason: duplicatepointing here. Use this thread as the single source of truth for LID handling across all integrations.Reorganized as a meta-issue as part of the 2026-04 issue triage. Original reporter (@Simplobot1) and all community contributors remain credited in the comment history.