[BUG] Problem with @lid remoteJid not returning real WhatsApp number

[SantiagoPeraltaQ]

Hi everyone,

Recently I’ve been facing an issue that seems to be related to WhatsApp’s new use of hidden IDs (@lid).

In some cases, when a user sends a message, the remoteJid field comes as something like:

1234567890@lid

instead of the expected:

1234567890@s.whatsapp.net

When this happens, Baileys does not provide the real WhatsApp number, making it impossible to reply to that user correctly.

In groups, sometimes the participant field still contains a valid @s.whatsapp.net, but in private chats there is no reliable way to map the @lid to the real JID.

This results in bots either ignoring the message or (worse) attempting to send replies to non-existent numbers.

I’ve seen some related discussions in recent issues, but I couldn’t find a concrete fix or workaround.
My questions are:

Is there any official plan or timeline for solving this @lid mapping issue?

Is there a recommended temporary workaround until an official patch is released?

Can we expect a function within Baileys that safely converts or normalizes @lid → @s.whatsapp.net where possible?

This issue is currently blocking production use of my project, and I’m sure other developers must be experiencing the same problem.

[wmenezes2020]

No Brasil já começou também, a maioria dos números chegam com esses números ocultos apenas com os IDs@jid ...

[Gecko2087]

Today, I also experienced this inconvenience. On a platform similar to Whaticket, using Baileys, I receive tickets with IDs, and on multiple occasions, these double, as some arrive with the original phone number and others with the ID.

I would like to know if anyone has managed to solve this problem. I appreciate any guidance.

[Zedmerlol]

check my answer about that:
#1692 (comment)

[elmasse]

is it possible to add the alpha version to npm alpha channel?

[abelacco]

This is big problem anyone fix this?

[gandalfhv]

Ya salió la solution al problema de los lids y los mensajes en espera https://github.com/WhiskeySockets/Baileys/releases/tag/v6.7.19

[Sutauruki]

Hi everyone,

Recently I’ve been facing an issue that seems to be related to WhatsApp’s new use of hidden IDs (@lid).

In some cases, when a user sends a message, the remoteJid field comes as something like:

1234567890@lid

instead of the expected:

1234567890@s.whatsapp.net

When this happens, Baileys does not provide the real WhatsApp number, making it impossible to reply to that user correctly.

In groups, sometimes the participant field still contains a valid @s.whatsapp.net, but in private chats there is no reliable way to map the @lid to the real JID.

This results in bots either ignoring the message or (worse) attempting to send replies to non-existent numbers.

I’ve seen some related discussions in recent issues, but I couldn’t find a concrete fix or workaround. My questions are:

Is there any official plan or timeline for solving this @lid mapping issue?

Is there a recommended temporary workaround until an official patch is released?

Can we expect a function within Baileys that safely converts or normalizes @lid → @s.whatsapp.net where possible?

This issue is currently blocking production use of my project, and I’m sure other developers must be experiencing the same problem.

I have a fix to this issue

const jid = msg?.key?.remoteJid;
if (!jid) return;

const phoneJid = await sock.signalRepository.lidMapping.getPNForLID(jid);

if (phoneJid) {
console.log("Phone number JID:", phoneJid); // e.g., 2348000000000@s.whatsapp.net
} else {
console.log("No mapped phone number found for this LID.");
}

works 100%

Phone number JID: 2348088xxx550:0@s.whatsapp.net

please follow me

i'm using "@whiskeysockets/baileys": "7.0.0-rc.9",