[GOWS] message.any event is generated and logged, but the webhook request does not reach n8n

[diMarkaJJamanoy]

Description

We are using WAHA with n8n to receive WhatsApp events through webhooks.

The WAHA session is working correctly and incoming WhatsApp messages are being received by WAHA without issue.

The message.any event is configured, and WAHA generates the event and its JSON payload correctly — this is visible in the logs.

However, the corresponding webhook request does not appear to reach n8n, and no n8n execution is ever created for that event.

We initially tested against the n8n Test Webhook and it worked correctly. After further testing, the same Test Webhook stopped triggering executions. We then created a completely new Webhook Trigger in n8n, on a different path, purely to rule out an issue with the original workflow — the result was the same: no execution.

This looks like a webhook delivery problem between WAHA and n8n, rather than an event-generation problem.

---

Environment

WAHA version	2026.8.2
Tier	CORE
Engine	GOWS
Platform	linux/x64

---

WAHA webhook configuration

• Event: message.any
• Attempts: 15
• Delay: 2 seconds
• Retry policy: Exponential
• HMAC: disabled / empty
• Custom headers: disabled

Production and Test webhook URLs are standard n8n webhook endpoints of the form:

https://<n8n-host>/webhook/<workflow-id>/waha        (production)
https://<n8n-host>/webhook-test/<workflow-id>/waha   (test)

---

Event generation

When an incoming WhatsApp message is received, WAHA generates a message.any event. A sanitized example from the WAHA log:

{
  "id": "evt_<redacted>",
  "session": "default",
  "event": "message.any",
  "payload": {
    "id": "false_<redacted>@lid_<redacted>",
    "timestamp": 1788439474,
    "from": "<redacted>@lid",
    "fromMe": false,
    "source": "app",
    "body": "<redacted>",
    "to": null,
    "participant": null,
    "hasMedia": false,
    "media": null,
    "ack": 2
  },
  "timestamp": 1788439474716,
  "metadata": {},
  "engine": "GOWS",
  "environment": {
    "version": "2026.8.2",
    "engine": "GOWS",
    "tier": "CORE",
    "browser": null,
    "platform": "linux/x64"
  }
}

The full payload contains additional WhatsApp metadata (message secrets, sender/recipient key hashes, phone numbers, JIDs, and contact names). All of that has been removed from this report as it is not needed to reproduce or diagnose the issue.

---

Important observation

The event is clearly generated by WAHA — the log shows the message.any event and its JSON payload in full.

However, immediately after the event is generated, we do not see a corresponding WebhookSender / HTTP POST log entry, nor any webhook response, in the surrounding WAHA logs.

We see the generated event:

message.any
<JSON payload>

but nothing equivalent to:

Sending POST...
POST request was sent with status code: XXX

for that same event. This makes it hard to tell whether the HTTP request is actually being attempted at all.

---

n8n configuration

• Webhook Trigger, HTTP Method: POST
• Tested against both the original workflow and a brand-new Webhook Trigger on a different path, to rule out a stale/duplicate registration — same result on both.
  (Webhook Trigger configuration screenshot attached.)

---

Tests performed

1. WAHA → n8n Test Webhook
Initially worked: the event reached n8n and created an execution. After further testing, the same Test Webhook stopped creating executions.

2. WAHA → n8n Production Webhook
No n8n execution is created when WAHA generates a message.any event.

3. New n8n Webhook Trigger (different path)
Also did not receive the event.

---

Expected behavior

WhatsApp
   ↓
WAHA / GOWS
   ↓
message.any
   ↓
HTTP POST
   ↓
n8n Webhook
   ↓
n8n Execution

Actual behavior

WhatsApp
   ↓
WAHA / GOWS
   ↓
message.any generated     ✅
   ↓
JSON payload generated    ✅
   ↓
Webhook delivery          ❓
   ↓
n8n execution             ❌

No corresponding execution appears in n8n.

---

Related issues

This may be related to previous GOWS webhook-delivery issues, though the symptoms are not identical:

• [GOWS] - Session silently stops sending webhook events after <stream:error> (media ack); status stays WORKING until manual restart #2151 — GOWS session silently stops sending webhook events while remaining WORKING, triggered by a repeating stream:error on a media ack; resolved by restarting the session, which flushed the backlog. In our case there is no stream:error in the logs, and the session was never restarted to test whether backlogged events would flush.
• [GOWS] - Webhook for incomming messages not working after random time. #1717 — GOWS incoming-message webhooks stop working after some time.
  In our case, the key difference is that the message.any event itself, along with its payload, is visible and complete in the WAHA logs. The failure appears to happen after event generation, during or before webhook delivery.

[flowpatch-reliability]

The missing WebhookSender line is the useful boundary here: it suggests this is failing before DNS/TLS/n8n, not at the HTTP response stage.

A deterministic isolation sequence would be:

1. From the WAHA container, POST the same payload to the production n8n URL with curl (proves routing/TLS and that the workflow is active).
2. Temporarily point WAHA at a minimal request-bin endpoint on the same network (proves whether any sender attempt leaves WAHA).
3. Restart only the GOWS session and note whether old events flush. If they do, the queue/consumer is stalled; if they do not, the event was never enqueued.
4. Correlate one event ID through four structured log points: generated, enqueued, dequeued/attempted, HTTP result.

Given 15 configured attempts but zero attempt log lines, I would inspect the subscription/queue handoff between message.any generation and WebhookSender first. Also, please avoid relying on /webhook-test/ for this test: n8n only keeps that route active while “Listen for test event” is open; the activated production route is the stable comparison.