[BUG] Call event returns non-phone JID (@lid) instead of the real WhatsApp number

[azeezeladl]

Hello, I am facing an issue with the call event in the latest version of the library.

When I receive an incoming call, the JID provided in the call payload does not contain the real phone number.
Instead of receiving something like:

2010XXXXXXXX@s.whatsapp.net

I always receive a value in this format:

169969455263976@lid

This value is not a phone number, and therefore I am unable to detect the caller’s real WhatsApp number.

Here is a real log from the call event:

===== WA RAW CALL EVENT =====
[
{
chatId: '169969455263976@lid',
from: '169969455263976@lid',
id: 'CB615F3BCC17E4A8E2682B5818A8A4A8',
date: 2025-12-03T04:58:42.000Z,
offline: false,
status: 'terminate',
isVideo: false,
isGroup: false
}
]

Problem Summary

Both chatId and from use a non-standard JID ending with @lid instead of @s.whatsapp.net.

The numeric value before @lid is not the real phone number of the caller.

This prevents my application from identifying who is calling and sending an auto-reply message.

Expected behavior

The call event should provide the caller's correct JID, for example:

@s.whatsapp.net

Questions

Is this a known issue in the current version of the library?

Is there a way to resolve or decode the @lid JID to retrieve the actual WhatsApp phone number?

Is this behavior caused by recent WhatsApp protocol changes related to call privacy?

Please let me know how I can correctly obtain the real caller number from the call event.

Thank you!

[Steph0329]

Normally in senderPn property comes the real number, I recently made the same mistake!

[Riders004]

Normally in senderPn property comes the real number, I recently made the same mistake!

SenderPn ?? Mybe is for group

[Riders004]

Hello, I am facing an issue with the call event in the latest version of the library.

When I receive an incoming call, the JID provided in the call payload does not contain the real phone number. Instead of receiving something like:

2010XXXXXXXX@s.whatsapp.net

I always receive a value in this format:

169969455263976@lid

This value is not a phone number, and therefore I am unable to detect the caller’s real WhatsApp number.

Here is a real log from the call event:

===== WA RAW CALL EVENT ===== [ { chatId: '169969455263976@lid', from: '169969455263976@lid', id: 'CB615F3BCC17E4A8E2682B5818A8A4A8', date: 2025-12-03T04:58:42.000Z, offline: false, status: 'terminate', isVideo: false, isGroup: false } ]

Problem Summary

Both chatId and from use a non-standard JID ending with @lid instead of @s.whatsapp.net.

The numeric value before @lid is not the real phone number of the caller.

This prevents my application from identifying who is calling and sending an auto-reply message.

Expected behavior

The call event should provide the caller's correct JID, for example:

@s.whatsapp.net

Questions

Is this a known issue in the current version of the library?

Is there a way to resolve or decode the @lid JID to retrieve the actual WhatsApp phone number?

Is this behavior caused by recent WhatsApp protocol changes related to call privacy?

Please let me know how I can correctly obtain the real caller number from the call event.

Thank you!

Still you can reject the call and send message using from or chatId

[robleds]

Somebody knows if in v7 this problem was solved?

[alessandropcostabr]

✅ RESOLVED — Same Pattern Works

This is related to #2154 and we've solved it in production!

The Root Cause

call events emit JIDs in different formats:

• Phone JID: 5511947763114@s.whatsapp.net ✅
• LID (Local ID): 123456789@lid ❌ Not a real phone!

Baileys doesn't always resolve LID to phone before emitting the event.

Our Solution: 3-Layer Fallback

Full guide: #2414

// Use this to resolve ANY JID that might be @lid:
const phone = await resolveLidToPhone(call.from, store, lidMap);
// Now you can safely use `phone` for your DB/API

Works for All Events

• ✅ call
• ✅ presence.update
• ✅ messages.upsert (sometimes)
• ✅ Any JID in any event

Tested in Production (6 accounts, 4k conversations)

100% success rate resolving @lid to real phone numbers.

Related issues:

• Incoming call events contain @lid without phone PN — cannot resolve caller number (calls only) [BUG] #2154 (same LID problem for calls)
• [DISCUSSION] LID Mapping Best Practices & Debugging Guide for Production #2414 (full LID mapping guide)

See our guide for complete implementation: #2417