My workflow works well, but when it comes to sending the message back to the recipient’s number, the message status stays PENDING and the message doesn’t arrive. How is it possible to resolve this issue? I use n8n through Cloudfy and integrate with WhatsApp through the Evolution API. I’ve already checked the input of each node and the information is correct. It just can’t send the message. Obviously, I’ve already verified that I’m not using the Test URL and my workflow is published. In Evolution, the Instance has the same name in the output node and is also active and connected to WhatsApp.
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
n8n version: 2.30.4 Database (default: SQLite): n8n EXECUTIONS_PROCESS setting (default: own, main): Running n8n via (Docker, npm, n8n cloud, desktop app): Operating system: windows 11
n8n
August 27, 2026, 5:49pm
2
Hey @Henrique_Weiss , while you wait for a response, here are some things that might help:
Suggested resources
Automatically matched to your question.
Docs:
Forum:
@jan , @edumats , @Zelite - you’ve helped with similar issues before, can you take a look?
Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here .
Hey @Henrique_Weiss Welcome to the n8n community!
I think hat isn’t your workflow, so stop auditing the nodes. A 200 with status PENDING that never advances is an open Evolution bug tied to WhatsApp’s move to @lid addressing: the number to LID mapping doesn’t get rebuilt, the send keeps using the plain @s.whatsapp.net address, and the server rejects it. MessageUpdate lands on ERROR even though the API told you 200.
Since you’re replying to an inbound message you already have what you need. Send to the remoteJid that came in on the trigger payload instead of the bare number, because the @lid form is the one still delivering. Reported on 2.3.7 and 2.4.0, still open:
opened 05:26PM - 13 Aug 26 UTC
## Summary
After re-pairing an instance, **every** message sent with a phone nu… mber as the
recipient ends in `ERROR` in `MessageUpdate` and is never delivered. The same
instance, at the same moment, delivers normally when the recipient is addressed
by LID. Before the re-pairing, the very same instance delivered fine to phone
numbers.
This is not a banned/limited number: sending manually from the WhatsApp app of
the sender phone to a fresh recipient works (see "What we ruled out").
## Environment
| | |
|---|---|
| Image | `evoapicloud/evolution-api:v2.3.7` (built 2025-12-05) |
| Evolution | 2.3.7 |
| Baileys | 7.0.0-rc.9 |
| Database | PostgreSQL (`DATABASE_PROVIDER=postgresql`) |
| Cache | Redis, `CACHE_REDIS_ENABLED=true`, `CACHE_REDIS_SAVE_INSTANCES=true` |
| Instance settings | `syncFullHistory: false`, `groupsIgnore: true`, `rejectCall: true` |
| Pairing | QR code |
## Steps to reproduce
1. Pair an instance by QR.
2. Send messages with `POST /message/sendText/{instance}` using
`{"number": "<E.164 digits>", "text": "..."}`. They deliver.
3. Log out and re-pair the same instance (any reason — we hit it after
recreating the container).
4. Send again, same endpoint, same payload shape, to recipients that have never
messaged the sender.
**Expected:** delivery, as before the re-pairing.
**Actual:** the API returns `200` with `status: PENDING` and a `key.id`; the
message shows up in the manager; and `MessageUpdate` records `ERROR`. Nothing
arrives.
## Evidence
Counting the whole instance history, split at the moment of the re-pairing.
Recipients are distinct people across many area codes; the "after" batch is a
single campaign of 46 messages.
| | address | outcome | count |
|---|---|---|---|
| before | phone (`@s.whatsapp.net`) | DELIVERY_ACK | 7 |
| before | phone | SERVER_ACK | 6 |
| before | phone | READ | 3 |
| before | phone | ERROR | 10 |
| before | LID (`@lid`) | DELIVERY_ACK + READ | 4 |
| **after** | **phone** | **ERROR** | **62** |
| **after** | **phone** | **any success** | **0** |
| after | LID | DELIVERY_ACK / READ / SERVER_ACK | 3 |
The LID sends in the "after" row were made minutes apart from failing phone
sends, on the same process, to the same person — one address works, the other
does not.
Two more observations that may help:
- **Incoming** messages from that same person arrive with `remoteJid` as
`<id>@lid`, never as `<phone>@s.whatsapp.net`.
- A send that eventually delivered recorded `ERROR`, `ERROR`, then
`DELIVERY_ACK` — a retry path exists and sometimes succeeds, but for
recipients with no prior conversation it never did.
## What we ruled out
- **Number health / spam restriction.** Sending by hand, from the WhatsApp app
of the sender number to a recipient that never talked to it, delivers
normally. The account is fine.
- **Credentials / connectivity.** `connectionStatus` is `open`, the API accepts
every request, and `/chat/whatsappNumbers` answers correctly for the same
numbers that fail to receive (`exists: true`).
- **Disk / temp files.** Host at 39% usage; container `/tmp` clean.
- **Recipient-specific issue.** The failing batch spans 46 different recipients
in unrelated area codes.
## Where we think it goes wrong
In baileys 7.0.0-rc.9, `LIDMappingStore.getLIDsForPNs` looks up the cache, then
`keys.get('lid-mapping', …)`, and only then falls back to USync via
`pnToLIDFunc`. `signalStorage.resolveLIDSignalAddress` uses that mapping to pick
the Signal session address on `loadSession`/`storeSession`.
Our reading is that the mapping is lost with the re-pairing and is not rebuilt
for recipients that never messaged the instance, so encryption keeps using the
PN address and the server rejects it. We could not confirm this from logs
because `LOG_BAILEYS=error` hides the `trace` line
(`No LID mapping found for PN user …; batch getting from USync`), and raising it
requires a restart, which on a production instance costs another pairing.
Happy to run any diagnostic that helps — we have a reproducible environment and
the full `Message`/`MessageUpdate` history.
## Impact
Any deployment using phone numbers as recipients — which is the documented and
natural way to use `sendText` — silently stops delivering after a re-pair. The
API keeps answering `200`, so monitoring based on the HTTP response reports
success while nothing reaches anyone. In our case a campaign of 46 messages
reported "sent" and delivered zero.
Hi @Henrique_Weiss
opened 12:36AM - 03 Jul 26 UTC
bug
### Welcome!
- [x] Yes, I have searched for similar issues on [GitHub](https://… github.com/EvolutionAPI/evolution-api/issues) and found none.
### What did you do?
### Describe the bug
Private messages are never delivered.
The API returns **201 Created**, but every private message remains permanently **PENDING**.
Group messages are delivered normally.
### Environment
* Evolution API: v2.3.7
* Railway
* PostgreSQL
* Redis
* WhatsApp Multi Device
### Steps to reproduce
1. Create a new instance.
2. Scan a new QR Code.
3. Wait until the instance is connected.
4. Send a message to a private contact.
5. The API returns 201 but the message stays PENDING forever.
### Expected behavior
The private message should be delivered.
### Actual behavior
* Private chats: ❌ Always PENDING
* Group chats: ✅ Working normally
* Receiving messages: ✅ Working normally
### Logs
```text
Sending message to xxxxxxxxx@s.whatsapp.net
status: 1
Update messages
status: 0
messageStubParameters: ["463"]
stream errored out
```
### Additional information
Already tested:
* New instance
* New QR Code
* Different private contacts
* Sending from Evolution UI
* Sending through `/message/sendText`
* n8n removed from the test
* Typebot removed from the test
The problem remains the same.
### What did you expect?
The issue only affects private chats.
What has already been verified:
* Fresh instance created from scratch.
* New QR Code scanned.
* WhatsApp connection established successfully.
* Receiving messages works correctly.
* Sending messages to groups works correctly.
* Sending messages to private contacts always remains in `PENDING`.
* The API returns HTTP `201 Created`.
* The logs show `Sending message...`, followed by `status: 0`, `messageStubParameters: ["463"]`, and sometimes `stream errored out`.
* The same behavior occurs when sending from the Evolution UI and through the `/message/sendText` endpoint.
* n8n and Typebot were removed from the tests, so they are not involved in the issue.
If any additional logs or debug information are required, I can provide them.
### What did you observe instead of what you expected?
When sending a message to any private WhatsApp contact, the Evolution API returns HTTP `201 Created`, but the message remains permanently in the `PENDING` state and is never delivered.
The logs show that Baileys attempts to send the message (`Sending message to...`), but the status changes to `0` and never progresses to a delivered state. In some cases, `stream errored out` also appears in the logs.
The same behavior occurs when sending from the Evolution UI and through the `/message/sendText` endpoint.
Receiving messages works correctly, and sending messages to WhatsApp groups also works correctly. The problem only affects private chats.
### Screenshots/Videos
_No response_
### Which version of the API are you using?
Evolution API: v2.3.7
Baileys: 2.3000.1042581539
### What is your environment?
Docker
### Other environment specifications
_No response_
### If applicable, paste the log output
_No response_
### Additional Notes
_No response_
Thank you for your help. I’ll test it as soon as possible.
It turns out the problem was in the Evolution API version itself. I had to downgrade to version 2.3.3 and it worked as it should. Thank you very much for the help anyway.
Good afternoon Henrique, how are you?
If I do a downgrade, will I need to redo all the instances? Can you tell me? I’m asking because these are instances that are working and belong to active clients.
Thank you
Ricardo, I didn’t need to redo or change absolutely anything in my workflow, infrastructure, instance, etc.
I understand perfectly.
I also use it in these projects, through Cloudfy.
Nothing. It worked as it should have.
Thanks man.
Big hug
