Webhook not firing (MESSAGES_UPSERT) and outbound messages "succeed" without delivery — instance connected, both directions failing silently

Start with the /webhook/set/{instance} configuration and the /message/sendText/{instance} endpoint, then reproduce both flows for instance afprospeccao2 while examining application logs and the Baileys event handling layer. Done means MESSAGES_UPSERT reaches the configured webhook and outbound requests either deliver messages or report an accurate failure instead of succeeding silently.

Welcome!

• Yes, I have searched for similar issues on GitHub and found none.

What did you do?

Environment

• Evolution API version: 2.3.7 (client self-identifies as this version in Integrations panel; attempted downgrade to 2.3.6 via Docker image tag did not take effect — image kept reporting 2.3.7)
• Deployment: Railway
• Baileys version: 2.3000.1045164762
• Instance name: afprospeccao2

Steps to reproduce (inbound)

1. Created a brand-new instance (afprospeccao2) from scratch after fully cleaning up old instance data (Redis keys, Postgres phantom instance records)
2. Connected the instance to WhatsApp — status shows "Connected"
3. Configured webhook via the UI: enabled, correct URL, event MESSAGES_UPSERT (confirmed in Settings → Behavior)
4. Sent a test message from another phone — message shows delivered/read (double blue check) on WhatsApp
5. No webhook call is received on the destination server (verified independently — manually POSTing a synthetic payload to the same endpoint works correctly)
6. Reconfigured the webhook via API directly (POST /webhook/set/{instance}) to rule out a UI persistence bug — API responded 201 with correct config
7. Sent another test message after reconfirming — still no webhook dispatch

Steps to reproduce (outbound)

1. n8n workflow calls /message/sendText/{instance} via HTTP Request node
2. The Evolution API call returns a success response — n8n marks the execution as "Succeeded"
3. No message is actually delivered to the WhatsApp recipient
4. This has been consistently observed across multiple executions (e.g. one batch of 5 messages, all returned success in the API/n8n but none were delivered)
5. messageStubParameters: ["463"] appeared consistently in these failed outbound deliveries in earlier debugging

What did you expect?

Inbound: the webhook should fire a MESSAGES_UPSERT event POST to the configured URL whenever a new message is received.

Outbound: a "success" response from /message/sendText should mean the message was actually delivered (or at minimum reflect real delivery status, not just that the API call was accepted).

What did you observe instead of what you expected?

Inbound: no webhook request is ever received on the destination server, despite the instance showing "Connected" and messages being confirmed delivered/read on WhatsApp. Confirmed the destination server itself works correctly by manually POSTing a synthetic payload to it (processed successfully). Also confirmed the webhook config is correctly persisted by re-setting it via direct API call, which returned 201 with the correct configuration — yet no dispatch occurs on real incoming messages.

Outbound: /message/sendText returns a success response and n8n marks the workflow execution as "Succeeded", but the message is never actually delivered to the recipient's WhatsApp. Observed across multiple executions, including one batch of 5 messages where all 5 "succeeded" at the API level but zero were delivered.

This suggests an issue in the underlying Baileys/WhatsApp event handling layer in this version — both inbound and outbound message flows silently fail after reporting success, with instance connection status appearing normal throughout.

Screenshots/Videos

No response

Which version of the API are you using?

2.3.7

What is your environment?

Windows

Other environment specifications

Deployment: Docker container on Railway. Instance name: afprospeccao2. Baileys version: 2.3000.1045164762.

If applicable, paste the log output

No raw application logs captured at time of reporting — all evidence gathered via API responses and n8n execution history, detailed in the reproduction steps above.

Additional Notes

This bug affects a production WhatsApp automation used for business messaging, causing both inbound customer messages and outbound automated messages to silently fail without any error indication in the API or n8n logs.