[WEBJS] - Labels are not applied via WAHA n8n node

[Arturooro10]

Title

Labels are not applied via WAHA n8n node (regression on 2025.10.3, engine: webjs, tier: pro)

Describe the bug

Using the WAHA n8n node "Put Chat Labels" against PUT /api/{session}/labels/chats/{chatid}, the node runs "successfully" but the label is not applied to the chat. This previously worked and stopped working after updating to 2025.10.3 (engine webjs, pro tier).

Version

{
  "version": "2025.10.3",
  "engine": "webjs",
  "tier": "pro"
}

Steps to Reproduce

1. In n8n, use WAHA node Labels → Put Chat Labels
2. Endpoint shown by the node: PUT /api/{session}/labels/chats/{chatid}
3. Inputs (from the node UI):
   • Session: session3
   • Chat id: e.g. 5215616241739@c.us (from previous node)
   • Labels payload:

     [
       { "id": "20" }
     ]

4. Node finishes without error and returns an empty string in Output
5. The expected label does not appear in WhatsApp UI and is not reflected by subsequent reads

Expected behavior

The provided label ID ("20") should be applied to the target chat and become visible/readable.

Actual behavior

• Node returns success (no error)
• Output is empty ""
• Label is not applied

Requests – Responses

From n8n execution (as shown in the node config/screenshot). If needed I can attach the raw HTTP trace, including status code and response headers.

Request (intended):

PUT /api/session3/labels/chats/5215616241739@c.us
Content-Type: application/json

[
  { "id": "20" }
]

Response (observed by node):

""   // empty string in Output panel

Docker Logs

⟦Please add related WAHA logs around the request time⟧

Screenshots

n8n node configuration and Output showing empty string (attached).

Additional context

• This exact flow worked before upgrading to 2025.10.3 (engine webjs)
• The label with ID 20 already exists

[kitobelix]

Seeing the same issue. Not just limited to n8n, im using it via API

[Arturooro10]

Quick update from my side: I managed to narrow the issue down and get a partial workaround.

What I’m seeing

• Labels are only applied when the WhatsApp ID (JID) ends with @lid.
• Using the same phone with @c.us, label changes fail / don’t apply.
• This used to work for me with @c.us, so it looks like WhatsApp changed behavior in a recent update.

Workaround I’m using now

1. I first send a simple message to the contact using the @c.us ID.
2. I read the reply and grab the from field, which comes back as number@lid.
3. I then call the “change label” request using that @lid ID — and labels apply correctly.

This works, but it’s pretty tedious to do for every contact.

Ask / suggestion

• Could @devlikepro normalize IDs internally or provide a helper endpoint to resolve @c.us → @lid before label operations?
• Alternatively, restoring compatibility so label updates accept both forms would keep existing flows working.

Hope this helps reproduce the issue and guide a fix. Happy to provide more details if needed.

[kitobelix]

I have another insight to add:

20/10/2025 14:03:10[14:03:10.824] INFO (10): request errored {"reqId":3039,"req":{"id":3039,"method":"POST","url":"/api/__redacted__c/labels","query":{},"params":{"path":["api","__redacted__c","labels"]}},"res":{"statusCode":400},"responseTime":4}
20/10/2025 14:03:10    err: {
20/10/2025 14:03:10      "type": "BadRequestException",
20/10/2025 14:03:10      "message": "Bad Request Exception",
20/10/2025 14:03:10      "stack":
20/10/2025 14:03:10          BadRequestException: Bad Request Exception
20/10/2025 14:03:10              at ValidationPipe.exceptionFactory (/app/node_modules/@nestjs/common/pipes/validation.pipe.js:107:20)
20/10/2025 14:03:10              at ValidationPipe.transform (/app/node_modules/@nestjs/common/pipes/validation.pipe.js:74:30)
20/10/2025 14:03:10              at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
20/10/2025 14:03:10              at async resolveParamValue (/app/node_modules/@nestjs/core/router/router-execution-context.js:148:23)
20/10/2025 14:03:10              at async Promise.all (index 0)
20/10/2025 14:03:10              at async pipesFn (/app/node_modules/@nestjs/core/router/router-execution-context.js:151:13)
20/10/2025 14:03:10              at async /app/node_modules/@nestjs/core/router/router-execution-context.js:37:30
20/10/2025 14:03:10      "response": {
20/10/2025 14:03:10        "message": [
20/10/2025 14:03:10          "colorHex must be a hexadecimal color"
20/10/2025 14:03:10        ],
20/10/2025 14:03:10        "error": "Bad Request",
20/10/2025 14:03:10        "statusCode": 400
20/10/2025 14:03:10      },
20/10/2025 14:03:10      "status": 400,
20/10/2025 14:03:10      "options": {},
20/10/2025 14:03:10      "name": "BadRequestException"
20/10/2025 14:03:10    }

That request used only color number, but colorHex was empty.

Likewise sending a color "13" (as number, ofc) it also complains:

20/10/2025 14:02:27    err: {
20/10/2025 14:02:27      "type": "BadRequestException",
20/10/2025 14:02:27      "message": "Bad Request Exception",
20/10/2025 14:02:27      "stack":
20/10/2025 14:02:27          BadRequestException: Bad Request Exception
20/10/2025 14:02:27              at ValidationPipe.exceptionFactory (/app/node_modules/@nestjs/common/pipes/validation.pipe.js:107:20)
20/10/2025 14:02:27              at ValidationPipe.transform (/app/node_modules/@nestjs/common/pipes/validation.pipe.js:74:30)
20/10/2025 14:02:27              at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
20/10/2025 14:02:27              at async resolveParamValue (/app/node_modules/@nestjs/core/router/router-execution-context.js:148:23)
20/10/2025 14:02:27              at async Promise.all (index 0)
20/10/2025 14:02:27              at async pipesFn (/app/node_modules/@nestjs/core/router/router-execution-context.js:151:13)
20/10/2025 14:02:27              at async /app/node_modules/@nestjs/core/router/router-execution-context.js:37:30
20/10/2025 14:02:27      "response": {
20/10/2025 14:02:27        "message": [
20/10/2025 14:02:27          "color must be a number conforming to the specified constraints"
20/10/2025 14:02:27        ],
20/10/2025 14:02:27        "error": "Bad Request",
20/10/2025 14:02:27        "statusCode": 400
20/10/2025 14:02:27      },
20/10/2025 14:02:27      "status": 400,
20/10/2025 14:02:27      "options": {},
20/10/2025 14:02:27      "name": "BadRequestException"
20/10/2025 14:02:27    }

Version 2025.10.4 PLUS, NOWEB.

[devlikepro]

@kitobelix do not mix the issues - different issues, different actions
Please create another one with body example, we'll check that 👍

[devlikepro]

WhatsApp changed behavior in a recent update.

Yeah, @lid is the future probably.
Try using LID API https://waha.devlike.pro/docs/how-to/contacts/#api---lids

helper endpoint to resolve @c.us → @lid before label operations?

But then you need to get "chat labels" by using @lid, so it make sense to use lid in your system as well for any communications.

We'll think about the whole lid vs pn soon and how it should work 👍