EvolutionAPI
Receives LID event instead of JID
Welcome!
- [x] Yes, I have searched for similar issues on GitHub and found none.
What did you do?
I have a very unusual problem... I have a solution that is all on WhatsApp via Evoluton, and one of my clients, who is a friend of mine, sends me messages and his number instead of sending the remojeid as WhatsApp, he sends it like this: "remoteJid": "221800818593797@lid", is there a way to fix this directly in Evolution? I need the number as WhatsApp because the automation only responds in this condition. If anyone can help me, I would be very grateful.
What did you expect?
Receive @whatsapp... like the others
What did you observe instead of what you expected?
Only, happne with this number...
Screenshots/Videos
Which version of the API are you using?
2.2.1
What is your environment?
Windows
Other environment specifications
No response
If applicable, paste the log output
No response
Additional Notes
No response
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 https://github.com/EvolutionAPI/evolution-api/issues/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: https://github.com/WhiskeySockets/Baileys/issues/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}([email protected]$)/); if (matchRemote) return matchRemote[0];
// Caso contrário, tenta com senderPn const matchSender = sender.match(/^55\d{10,12}([email protected]$)/); 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?
Same problem here (V.2.3.3 - latest). It works fine with IOS. With Android still have the @lid issue! Replacing phone@lid for [email protected] didn´t work for me!
update evoapicloud/evolution-api:latest (2.3.6) it solved the problem
This solved the issue for me.
I solved. I wrote in portuguese on another thread and now I don't want to write it in english, so translate it hahha. Eu resolvi. Fiz backup do banco. Uso docker, usei a 4.4.0 do chatwoot e a 2.3.6 do evolution.
Não dá pra fazer upgrade da v3 pra v4 pq muda muita coisa no banco, e são coisas que não tinham na minha versão do postgres.
Tive que subir a versão 14 do postgres tb.
Depois restaurei no banco novo o backup.
Ficou lindo.
Na versão 2.3.6, algumas mensagens estão chegando apenas com @lid, sem o número real em nenhum outro atributo..
Talvez, uma sugestão, seria o contato no banco de dados, que agora fica com remoteJid, ter um remoteJidAlt também, e deixar no remoteJid só o número real..
