[CHATWOOT] - Some contacts are duplicated with @lid

[WilliamSantos96]

Describe the bug

It was not possible to identify a pattern or reproduce the error, as it only occurs with some contacts. For no apparent reason, contacts are duplicated in Chatwoot, even though a contact already exists with the attributes: WhatsApp Chat ID, WhatsApp JID, and WhatsApp LID.
This new contact is saved only with @lid in the identifier field.

Version

{
  "version": "2026.1.3",
  "engine": "GOWS",
  "tier": "PLUS"
}

Steps

1. Contact and conversation already exist in Chatwoot.
2. For no apparent reason, a new contact is created and with it a new conversation.
3. This new contact does not return the phone number, only the @lid in the identifier field.

Expected behavior

If there is already a contact saved in Chatwoot, it should be kept and not duplicated with @lid.

Suggestion

Before creating a new contact in Chatwoot, search for @c.us using @lid or phone number in Chatwoot.

Screenshots

This image contact was created, but there was already an ongoing conversation with another contact representing the same person.

[bergpinheiro]

@devlikepro I've received some reports from the Brazilian community. Although I haven't been able to reproduce it, the case below occurred in November 2025 in the GOWS 2025.11.2 version, but only this member was able to provide me with the payload. It seems to be an isolated case. I myself have it in production using the Waha Chatwoot app integration and haven't been able to reproduce it.

Duplicate message Webhook Events for the Same WhatsApp Message ID (LID vs JID). Creating a new contact and a new conversation with the same message!

Summary

WAHA is emitting two separate message webhook events for the same WhatsApp message, causing downstream systems to process the same message twice.

Both events represent the same logical WhatsApp message, sharing the same internal WhatsApp message ID, but they differ in sender identifiers (@lid vs @c.us) and payload structure.

This behavior was observed and reported by a member of the Brazilian WAHA community.

---

Environment

• WAHA Version: 2025.11.2
• Engine: GOWS
• Tier: PLUS
• Event type: message
• Execution mode: production

(All values extracted directly from the webhook payload.)

---

Core Evidence

Both webhook events contain the same WhatsApp internal message identifier:

payload._data.Info.ID = AC2AB3184AC4AEB3E0527911B838398F

Despite this, WAHA emits two distinct webhook events.

---

Key Differences Between the Events

1. Sender identity format

• Event A (LID-based):

from: ********9836@lid

• Event B (JID-based):

from: 55********04@c.us

---

2. payload.id changes

The payload.id is derived from the from field.
Because from changes (@lid vs @c.us), the payload.id also changes, even though the underlying WhatsApp message is the same.

---

3. Payload enrichment level

• One event is delivered with minimal data
• A second event arrives later with additional metadata (PushName, device metadata, contextInfo)

This suggests a multi-stage message resolution, likely related to WhatsApp Multi-Device or LID resolution.

---

Payload Examples (Redacted)

Event 1 — LID-based (enriched)

{
  "event": "message",
  "session": "mysession_waha",
  "environment": {
    "version": "2025.11.2",
    "engine": "GOWS",
    "tier": "PLUS"
  },
  "payload": {
    "id": "false_********9836@lid_AC2AB3184AC4AEB3E0527911B838398F",
    "from": "********9836@lid",
    "fromMe": false,
    "body": "Oi",
    "_data": {
      "Info": {
        "ID": "AC2AB3184AC4AEB3E0527911B838398F",
        "Sender": "********9836@lid",
        "SenderAlt": "55********04@s.whatsapp.net",
        "PushName": "WD",
        "Timestamp": "2025-11-17T13:23:00-03:00"
      },
      "Message": {
        "extendedTextMessage": {
          "text": "Oi",
          "contextInfo": {
            "entryPointConversionSource": "click_to_chat_link"
          }
        }
      }
    }
  }
}

---

Event 2 — JID-based (initial)

{
  "event": "message",
  "session": "mysession_waha",
  "environment": {
    "version": "2025.11.2",
    "engine": "GOWS",
    "tier": "PLUS"
  },
  "payload": {
    "id": "false_55********04@c.us_AC2AB3184AC4AEB3E0527911B838398F",
    "from": "55********04@c.us",
    "fromMe": false,
    "body": "Oi",
    "_data": {
      "Info": {
        "ID": "AC2AB3184AC4AEB3E0527911B838398F",
        "Sender": "55********04@s.whatsapp.net",
        "Timestamp": "2025-11-17T13:22:58-03:00"
      },
      "Message": {
        "extendedTextMessage": {
          "text": "Oi"
        }
      }
    }
  }
}

---

Observed Behavior

From the webhook consumer perspective:

• Two different webhook events are received
• Both represent the same WhatsApp message
• They differ in:
  • from (@lid vs @c.us)
  • payload.id
  • metadata completeness
• Both share the same WhatsApp internal message ID (Info.ID)

As a result, downstream systems interpret these events as two distinct messages.

---

Problem Description (Technical)

WAHA emits multiple message events for a single WhatsApp message when the sender identity is resolved through different identifiers (LID vs JID), without consolidating or correlating these events at the webhook level.

The WhatsApp internal message ID (payload._data.Info.ID) remains stable across events, but it is not exposed or enforced as the canonical message identifier in the webhook contract.

---

Impact on Integrations

This behavior may cause:

• Duplicate message ingestion
• Duplicate background jobs
• Duplicate conversations or messages in downstream platforms
• Non-idempotent webhook processing

---

Additional Notes

• This report focuses only on the observed payload behavior
• No assumptions are made about WAHA internal implementation
• No solution or workaround is proposed here

---

Reported by: Brazilian WAHA community member
Context: Production usage with webhook-based integrations

[OrionZap]

I noticed that this happens when there's no previous conversation and you receive a call on WhatsApp. In Chatwoot, a contact @lid is created with the notification message of the incoming call. And this ends up generating this duplication. But this doesn't happen when there was already a conversation, and the call is received.

[WilliamSantos96]

@OrionZap This happens even if a previous conversation has already started. If there is already an ongoing conversation with the contact, in some cases a new conversation is being created to record the call.

[bergpinheiro]

@OrionZap This happens even if a previous conversation has already started. If there is already an ongoing conversation with the contact, in some cases a new conversation is being created to record the call.

Essa conversa que ja existe foi criado manualmente o contato?

---

Was this existing conversation manually created as a contact?

[OrionZap]

@OrionZap This happens even if a previous conversation has already started. If there is already an ongoing conversation with the contact, in some cases a new conversation is being created to record the call.

Essa conversa que ja existe foi criado manualmente o contato?

Nos casos que presenciei, não existia contato nem conversa. Ao receber a chamada no WhatsApp, criou-se um contato nome 737384749@lid e foto, sem outros atributos. Logo após o lead mandou uma mensagem de texto, onde gerou outro contato, dessa vez com os atributos preenchidos.

---

In the cases I witnessed, there was no contact or conversation. Upon receiving the call on WhatsApp, a contact was created with the name 737384749@lid and a photo, without any other attributes. Soon after, the lead sent a text message, which generated another contact, this time with the attributes filled in.

[devlikepro]

I guess this is where Chatwoot's "merge contacts" feature comes in really handy :D

The problem is that the first time a call or message is received, there's likely no c.us => lid mapping—here's why:

name 737384749@lid and photo, without any other attributes.

Therefore, until we have a @c.us => @lid mapping in store, we likely won't be able to do anything about it.

Ideally, we should switch all "check contact existence" calls to use @lid so that our blocking mechanism works properly and doesn't create two contacts for c.us/lid 🤔

Thanks everyone for the details!
We'll check this out and try to avoid similar issues, but for now, the solution is to merge your contacts in Chatwoot...

[WilliamSantos96]

@devlikepro I monitored the situation and noticed a few things.

1 - When a Chatwoot user creates a new contact, the chat_id, lid, and jid attributes have not yet been filled in, which is normal, since they are updated with the customer's response.

2 - When the customer responds to this conversation, a new contact and conversation is created within Chatwoot, because only the @lid was returned in the payload.

3 - Many contacts are being inserted with the chat_id in place of the name and without filling in the phone number in Chatwoot.

4 - I tried to create an automation to retrieve the @lid whenever a contact is created manually in Chatwoot, but in most cases the @lid is not returned due to WhatsApp permissions, which apparently only allow consulting the @lid once there is customer interaction.

My suggestion: Waha should verify the phone number through @lid before creating the contact in Chatwoot. From what I've seen, this is already being done, but in some cases it has failed. However, in the tests I've done, whenever there is @lid, it is possible to return the phone number. This allows the phone number to be the key field in maintaining contacts, avoiding duplication of contacts and conversations, which causes a lot of confusion, since the new conversation is usually assigned to another user, and users have difficulty locating this new conversation, especially in environments with many users and restrictions on viewing conversations.

Example of contact payload that did not return the phone number:

{
    "level": 30,
    "time": 1769780387336,
    "pid": 7,
    "hostname": "d998c5c25d58",
    "reqId": 19103,
    "req": {
        "id": 19103,
        "method": "GET",
        "url": "/api/Juridico/lids/12345678@lid",
        "query": {},
        "params": {
            "path": [
                "api",
                "Juridico",
                "lids",
                "12345678@lid"
            ]
        }
    },
    "res": {
        "statusCode": 200
    },
    "responseTime": 8,
    "msg": "request completed"
}

{
    "level": 30,
    "time": 1769780387397,
    "pid": 7,
    "hostname": "d998c5c25d58",
    "app": "ChatWoot",
    "component": "WAHACallAcceptedConsumer",
    "jobId": "606",
    "msg": "Created contact for chat.id: 12345678@lid, contact.id: 527c0983-9583-4afe-ba32-03c0756446dc"
}

In cases where the contact is created with the phone number, the log shows that Waha consulted /api/session/lids/pn/@c.us before creating the contact:

{
    "level": 30,
    "time": 1769794596796,
    "pid": 7,
    "hostname": "d998c5c25d58",
    "reqId": 31994,
    "req": {
        "id": 31994,
        "method": "GET",
        "url": "/api/session/lids/987654321@lid",
        "query": {},
        "params": {
            "path": [
                "api",
                "Omnis",
                "lids",
                "987654321@lid"
            ]
        }
    },
    "res": {
        "statusCode": 200
    },
    "responseTime": 1,
    "msg": "request completed"
}
{
    "level": 30,
    "time": 1769794596798,
    "pid": 7,
    "hostname": "d998c5c25d58",
    "reqId": 31995,
    "req": {
        "id": 31995,
        "method": "GET",
        "url": "/api/contacts?session=session&contactId=123456789%40c.us",
        "query": {
            "session": "Session",
            "contactId": "123456789@c.us"
        },
        "params": {
            "path": [
                "api",
                "contacts"
            ]
        }
    },
    "res": {
        "statusCode": 200
    },
    "responseTime": 1,
    "msg": "request completed"
}
{
    "level": 30,
    "time": 1769794596799,
    "pid": 7,
    "hostname": "d998c5c25d58",
    "reqId": 31996,
    "req": {
        "id": 31996,
        "method": "GET",
        "url": "/api/session/lids/pn/123456789@c.us",
        "query": {},
        "params": {
            "path": [
                "api",
                "Session",
                "lids",
                "pn",
                "123456789@c.us"
            ]
        }
    },
    "res": {
        "statusCode": 200
    },
    "responseTime": 0,
    "msg": "request completed"
}
{
    "level": 30,
    "time": 1769794596828,
    "pid": 7,
    "hostname": "d998c5c25d58",
    "app": "ChatWoot",
    "component": "WAHAMessageAnyConsumer",
    "jobId": "123519",
    "msg": "Created contact for chat.id: 987654321@lid, contact.id: 365530ff-2cb8-4190-a9c8-eb4d206ebba5"
}

This is how the contact is being entered in most cases:

[DyM-Electronica]

Still reproducible on 2026.3.4 / GOWS / PLUS. Adding data that I think changes the conclusion reached earlier in this thread — specifically:

Therefore, until we have a @c.us => @lid mapping in store, we likely won't be able to do anything about it.

That is true at the moment the first message arrives, but the mapping is not permanently missing — it shows up shortly after. Nothing ever revisits the placeholder contact, so a temporary condition gets frozen into a permanent duplicate.

Evidence

We accumulated 96 placeholder contacts (identifier <lid>@lid, phone_number null) between 2026-04-05 and 2026-07-25, across 100 conversations holding 1276 inbound messages that agents never saw — they were replying in the @c.us thread while the customer wrote in the @lid one.

When I went back and re-resolved each of those 96 LIDs through the API:

GET /api/{session}/lids/{lid}

85 of 96 returned a phone number. Only 11 still return {"lid": "...", "pn": null}.

So for ~89% of the duplicates, the data needed to create the contact correctly was available in WAHA's own store — just not yet at the instant the first message landed.

Where it happens

LidContactInfo.PublicContactCreate() in apps/chatwoot/contacts/WhatsAppContactInfo.js:

const jid = await this.jid();   // -> findPNByLid(lid), null when the store doesn't know it yet
let result;
if (jid) {
  result = await jid.PublicContactCreate();
} else {
  result = {
    inbox_id: 0,
    identifier: this.chatId,   // <lid>@lid
    name: this.chatId,
  };
}

The else branch is a reasonable fallback for the first message. The problem is that it is never revisited: every later message from that LID resolves to the placeholder contact in Chatwoot, so the customer stays split in two even after WAHA learns the mapping.

Worth noting the inbound payload already carries the phone number in _data.Info.SenderAlt (5730000000@s.whatsapp.net) even on messages where findPNByLid returns null — so in many cases the answer is in the event itself.

Suggestion

Rather than only fixing the create path, self-heal the ones already created. Any of these would do it:

1. On an incoming message whose Chatwoot contact has waha_whatsapp_lid set but no phone_number, retry findPNByLid (and/or fall back to SenderAlt); if it resolves, patch the contact with phone_number + waha_whatsapp_jid.
2. Same as above but driving Chatwoot's native contact merge when a @c.us contact with that phone already exists — which is the actual duplicate case.
3. Failing both, a maintenance endpoint (POST /api/{session}/chatwoot/repair-lid-contacts or similar) so operators can run it themselves.

Option 1 alone would have prevented ~89% of our duplicates, since the mapping was available well before the second message arrived.

Workaround we are running

Until this is fixed we run an external sweep every 4h: find Chatwoot contacts with identifier %@lid and no phone, resolve each via GET /api/{session}/lids/{lid}, and merge into the real contact with Chatwoot's ContactMergeAction (or just set the phone when no twin exists). It cleared 84 of the 96 with no errors.

One caveat for anyone copying this: the bulk endpoint GET /api/{session}/lids?limit=5000 did not return every mapping — 3 of our LIDs were missing from the full listing but resolved fine through the per-LID endpoint. Worth a look on its own.

[bergpinheiro]

@DyM-Electronica Did you test it on the latest version 2026.7.1?