Incoming WhatsApp messages via Waboxapp work, but reply fails due to phone number modification

Questions
1

Hi everyone,

I’m using n8n with Waboxapp to handle WhatsApp messages.

  • Incoming messages are received correctly via webhook.

  • The workflow runs fine and processes the message.

  • However, when I try to reply through Waboxapp, the message is not sent.

The issue seems to be that the phone number is modified somewhere in the flow (format/structure changes), and Waboxapp does not accept it when sending the reply.

:warning: Important: I don’t want to use the official WhatsApp Business API.

My questions:

  • Is there a specific phone number format required by Waboxapp for replies?

  • Should I reuse a specific field from the incoming payload instead of the transformed number?

  • Does Waboxapp require a conversation/session ID to send replies?

Any advice or workaround would be appreciated. Thanks!

2

Hi, @Javier_Chirivella !

Since incoming messages already work, this isn’t an n8n issue.

In most Waboxapp setups, reply failures happen because the phone/chat ID is being altered in the workflow.

Waboxapp expects the exact same identifier received in the webhook (no formatting, no +, no transformations). If you rebuild or format the number, the message won’t be sent.

There’s no separate conversation/session ID required — just make sure you reuse the original from / chatId field exactly as received.

Hope that helps.

1 Like
3

I’m using Waboxapp to receive WhatsApp messages via webhooks in n8n. I’ve run into an issue where the contact[uid] field is returning a LID (e.g., 270342438293603@lid) instead of the actual phone number ([email protected]).

The Problem:

  1. Identification: I cannot match the incoming message to my database because the phone number is missing from all JSON fields (it’s not in contact[name] or message[display_name] either).

  2. Replying: When I try to send a message back using this UID, the API fails or the message is never delivered because it’s not a valid phone destination.

Context:

  • This seems to happen with new contacts or users not saved in the phone’s address book.

  • I am using a virtual number linked to Waboxapp.

Question: Has anyone found a way to “force” the webhook to reveal the real phone number or a method to resolve the @lid back to a @c.us JID within n8n?

Thanks for the help!

Captura de pantalla 2026-02-02 a las 20.47.06
Captura de pantalla 2026-02-02 a las 20.47.06490×374 27.6 KB

4

Hi @xiri

Welcome to the n8n community! :tada:

When WhatsApp returns a contact[uid] in @lid format, it should be treated as a valid and definitive contact identifier, even if the phone number is not yet available.

Best practice: DO NOT rely on phone number as primary key.

Instead:

  • Use contact[uid] as the unique user ID
  • Accept that the phone number may:
    • Never arrive
    • Arrive only after new interactions
  • Structure your flow to work independently of the number
Recommended node sequence

1. Webhook Waboxapp data input Receives the payload with:

  • contact[uid]
  • contact[name]
  • message[body][text]

2. IF – Is it @lid? Check if contact doesn’t have a phone number yet Condition:

{{ $json["contact[uid]"].endsWith("@lid") }}
  • TRUE → contact without phone
  • FALSE → resolved contact (@c.us)

3. Set – Normalize contact Create a “standard object” for the entire flow Typical fields:

  • user_id → contact[uid]
  • name
  • phone (or null)
  • channel

This node is essential to keep the flow clean.

4. Database (Upsert) Create or update the user

  • Unique key: user_id
  • Doesn’t depend on phone
  • Works with @lid or @c.us

5. IF – Can send message? Protection before sending Condition:

{{ !$json["user_id"].endsWith("@lid") }}
  • TRUE → Send message normally
  • FALSE → Go to fallback

6. Send Message (Fallback) Safe message when still @lid

1 Like