Baileys engine: outbound first message to an unsaved contact shows as an unidentified LID on our own linked phone — any way to force PN addressing on send?

[oricardodapg]

Version: v0.10.10 (build 20260724)
Deployment: Docker on EasyPanel — Postgres + Redis adapters, local storage
Engine: Baileys (@whiskeysockets/baileys@7.0.0-rc13)

What we see

When we send the first message through the API to a number that has never messaged the session and is not saved in the phone's address book, the chat that shows up on our own linked phone (the account's primary device) appears as an unidentified id — no name, no number.

The message itself is delivered fine, so this is not #830. In our own app the contact renders correctly; only the linked phone shows the unidentified label. As soon as the contact replies, the name appears there too.

What we already ruled out on our side

• We address every send as <e164>@c.us, never @lid.
• We call GET /sessions/{id}/contacts/check/{number} before every send, and it returns whatsappId: <e164>@c.us — so the id we hand to the gateway is already the phone dialect.
• Log of a real send (number redacted):
  [OpenWA send] chatId=55XXXXXXXXXXX@c.us -> status=201

So the PN → LID conversion seems to happen below our API call, inside the gateway/engine layer.

Numbers

Across 69 individual chats on one account: contacts who had replied show a name in ~80% of cases; contacts who never replied show as unidentified in ~74%; a couple show the raw number instead. The behavior started the day after we switched the engine from whatsapp-web.js to Baileys, which matches #666 (rc13 shipped in v0.10.1).

Question

Does the Baileys adapter address outbound chats using the LID jid, and is there any setting to force phone-dialect (PN) addressing on send?

We read the changelogs through v0.23.3 and found LID work on the read side (blocklist, group metadata, contacts) but nothing about outbound addressing — before scheduling an upgrade that costs a re-pair across all our sessions, we would like to know whether this area was touched.

[Junaid-PK]

Yes. In v0.10.10, the Baileys adapter deliberately resolves a phone-dialect chat ID to its known LID immediately before sending.

The exact path is:

1. sendTextMessage calls toDeliverableJid(chatId).
2. For @c.us / @s.whatsapp.net, that method converts the input to the Baileys PN form and calls signalRepository.lidMapping.getLIDForPN(pn).
3. If a mapping exists, it passes the returned LID to sock.sendMessage; only an unmapped or failed lookup falls back to the original phone JID.

That behavior is already present in the v0.10.10 tag and its recipient resolver. So the PN → LID conversion you inferred is happening inside OpenWA/Baileys even though the REST boundary correctly reports @c.us.

There is no configuration flag in that path to force PN addressing. The conversion is intentional: the code comment records that LID-migrated contacts can reject a PN-addressed send with ack 463 (missing tctoken), while the LID-addressed send succeeds. Current main still uses the same policy (current implementation).

Therefore:

• Upgrading solely to force PN will not change this; current versions still prefer the mapped LID.
• Forcing PN locally would risk turning this display issue into real delivery failures for migrated recipients.
• The unidentified chat on the linked phone is a contact/display synchronization issue after the LID-addressed first send, not evidence that your API supplied the wrong dialect.

The practical workarounds are to save/synchronize the contact before the first outbound message, or tolerate the unidentified label until WhatsApp learns the PN↔LID/contact association (for example after a reply). If the message is delivered, keeping the adapter LID routing is the safer behavior.

[Amit123103]

From what I understand, Baileys can resolve a PN JID to a LID internally during the send process, even if we pass the recipient as <e164>@c.us.
I don't think there is currently a setting to force PN addressing and prevent that conversion. The newer LID-related changes seem to improve the PN/LID mapping rather than provide an option to disable LID usage.
I'd recommend testing the latest Baileys release with a single session first before upgrading all sessions, especially if re-pairing is required.
If anyone knows of a supported way to force PN addressing on outbound messages, I'd be interested to know.

[eryoungboy]

I reproduced this issue and tracked it down to OpenWA’s Baileys send path, not the API input.

Even if you send:

<e164>@c.us

OpenWA can still resolve that phone-number JID to a LID before calling Baileys sendMessage().

The relevant logic is in:

src/engine/adapters/baileys-messaging.ts

inside toDeliverableJid().

The current behavior is effectively:

const pn = this.host.toEngineJid(chatId);

const lid =
  await this.sock().signalRepository?.lidMapping?.getLIDForPN(pn);

return lid ?? chatId;

So the flow becomes:

<e164>@c.us
    ↓
<e164>@s.whatsapp.net
    ↓
<LID>@lid
    ↓
sock.sendMessage()

That matches the behavior you described: the API receives a PN-style JID, but the actual send can still become LID-addressed below the API layer.

I tested the same scenario with bare Baileys using:

const result = await sock.onWhatsApp(phone);
const jid = result[0].jid;

await sock.sendMessage(jid, {
  text: 'Bare Baileys test',
});

Baileys returned:

<e164>@s.whatsapp.net

and when sending directly to that JID, the linked phone displayed the actual phone number correctly instead of Unknown user.

The important difference was that bare Baileys kept the top-level conversation PN-addressed:

Using PN identity for @s.whatsapp.net conversation

while still using LIDs internally where needed for device/session resolution.

The fix I tested in OpenWA was changing toDeliverableJid() to:

private async toDeliverableJid(chatId: string): Promise<string> {
  return this.host.toEngineJid(chatId);
}

So OpenWA now does:

<e164>@c.us
    ↓
<e164>@s.whatsapp.net
    ↓
sock.sendMessage()

and lets Baileys handle LID resolution internally.

After rebuilding, the logs changed to:

finalJid="<e164>@s.whatsapp.net"
usedLid=false

LIDs still appeared internally in session fetching / wireJids, which is expected, but the conversation itself remained PN-addressed.

Most importantly, the linked phone now showed the correct phone number.

I also tested a number that had previously appeared as Unknown user. After reconnecting the WhatsApp account and sending through the fixed PN-addressed path, the existing Unknown user chat immediately changed to display the correct phone number.

So yes:

• The PN → LID conversion is happening below the API layer.
• Sending <e164>@c.us from your application does not guarantee the actual Baileys send stays PN-addressed.
• In the version I tested, there is no config switch to force PN addressing.
• The adapter logic itself needs to be changed, or this behavior needs to be made configurable.

One thing worth noting: the existing code comments mention that PN-addressed sends to some LID-migrated accounts may fail with ack error 463 / missing tctoken. That is probably why the LID resolution was added in the first place.

However, with current Baileys, PN-addressed sends still perform LID-aware device/session resolution internally, so forcing the top-level conversation JID to @lid appears unnecessary in this case and is what caused the linked-phone identity issue.

[rmyndharis]

Thanks @eryoungboy for the reproduction, and for confirming the mechanism rather than just the symptom.

Your reading of the send path is correct: toDeliverableJid() resolves a phone-dialect 1:1 id to the contact's LID before sock.sendMessage, and only an unmapped id falls back to the PN. Nothing changed there in v0.24.0; the LID work since your report has all been read-side (contacts, chats, group metadata, RESOLVE_LID_TO_PHONE).

The LID preference is deliberate, and we would not remove it. We verified live that WhatsApp rejects PN-addressed 1:1 sends to LID-migrated accounts with ack 463 ("missing tctoken") while the same send addressed to the LID delivers; the comment above toDeliverableJid records this and tests pin it. Your bare-Baileys run did not hit it because those recipients were not in the migrated population. Dropping the preference would trade a cosmetic label on the linked phone for silent delivery failures on migrated contacts.

The proposed patch also removes the recordLidMapping() write-back, and that mapping is what lets the ownership check match a cold contact's first replies to the phone-dialect chat id; without it those messages can be rejected as not belonging to that chat.

So there is no supported way to force PN today, and no flag is planned. The label clears once WhatsApp associates the two ids, typically after the first reply. Related on the cold-contact side, #830 stays open and upstream-blocked.