[META] @lid vs @jid handling — tracking umbrella

@Simplobot1

Meta-issue consolidating all open reports about the @lid identifier replacing @s.whatsapp.net / JID.
Please do not open new @lid-related issues — comment here instead.

Background

WhatsApp is rolling out @lid (Linked ID) identifiers for some users — it replaces the classical phone-number-based @s.whatsapp.net JID 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

remoteJid arrives as NNNNNNNNNN@lid instead of phone-based JID, breaking downstream automations (n8n, Typebot, Chatwoot)
messages.upsert / messages.update events started arriving with @lid only, no phone number
Outgoing events carry @lid intermittently for the same contact

API endpoints / database

GET /chat/findContacts returns stale @lid identifiers after WhatsApp META update
Replying to @lid JID via HTTP Request returns 400 "exists: false"
Error: Unknown argument "lid". Did you mean "id"? when sending messages
Chat table stops creating new entries for @lid contacts (since late Sep 2025)

Integrations

Typebot: sends to @lid instead of JID, resulting in BadRequestException jidOptions.exists false
Chatwoot: duplicate contacts created (one with @lid, one with phone JID); historical import fails for @lid conversations (syncFullHistory=true has no effect)
n8n / automations: lookups based on phone number fail because webhook brings @lid

Group events

Group exit events carry @lid instead of JID of the leaving member

Status

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 @lid issues are being closed with state_reason: duplicate pointing 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.

same here

@lid

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?

@lid

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

@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

@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

@lid

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!

fix: end-to-end Chatwoot ↔ WhatsApp 双向闭环

@lid

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.

@lid

mensageria: responder contatos @lid (sem telefone) no WhatsApp

Evolution API version: v2.3.7 (Docker: evoapicloud/evolution-api:latest)
Integration: Chatwoot
Related to: #1872, #2324

What 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 remoteJid arrives in @lid format, but remoteJidAlt is completely absent from the payload (not just empty — the key doesn't exist at all). Since the Chatwoot integration relies on remoteJidAlt to 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 remoteJidAlt field 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' but remoteJidAlt completely missing (not just
empty, absent from the key). This caused createConversation to crash
with TypeError: 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 remoteJidAlt is absent, so the
conversation still gets created (contact shows up identified by LID
instead of phone number) instead of crashing silently.

fix(whatsapp): restore reply/quote contextInfo in prepareMessage

Navigation Menu

Repository navigation

[META] @lid vs @jid handling — tracking umbrella #1872

Background

Known symptoms

Webhook / event payload

API endpoints / database

Integrations

Group events

Status

For maintainers

Cause and Context

Possible Solutions and Workarounds

Example Code Adaptation

10 remaining items

What happened

Logs

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[META] @lid vs @jid handling — tracking umbrella #1872

Description

Background

Known symptoms

Webhook / event payload

API endpoints / database

Integrations

Group events

Status

For maintainers

Activity

albanirneves commented on Aug 25, 2025

M4rdine commented on Aug 25, 2025

NestorMiniDEV commented on Aug 26, 2025

Mdmartinez97 commented on Aug 27, 2025

HELIOPOTELICKI commented on Aug 27, 2025

JulioLang commented on Aug 27, 2025

andres99x commented on Aug 28, 2025

kcifuentes commented on Aug 28, 2025

Cause and Context

Possible Solutions and Workarounds

Example Code Adaptation

rrodriguescs commented on Aug 30, 2025

andres99x commented on Aug 31, 2025

tomatoes-prog commented on Sep 4, 2025

andres99x commented on Sep 4, 2025

fbeas commented on Sep 9, 2025

brasiljh commented on Sep 20, 2025

10 remaining items

jhon7999 commented on Aug 10, 2026

abdulsametkarakayali commented on Sep 3, 2026

What happened

Logs

abdulsametkarakayali commented on Sep 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions