Summary: An n8n bot (integration) whose config has enabled: false keeps sending HTTP calls to its webhookUrl on incoming WhatsApp message events. On v2.3.7 we observed hundreds of POST requests per day to the bot's webhookUrl while the bot record had enabled = false; traffic only stopped after the bot record was deleted via DELETE /n8n/delete/:id/:instanceName and the module env N8N_ENABLED=false was in place.
Environment: Evolution API v2.3.7 (Docker Swarm, PostgreSQL persistence, RabbitMQ events enabled).
Endpoints involved:
POST /n8n/create/:instanceName (bot config with enabled flag)POST /n8n/changeStatus/:id/:instanceName (enable/disable)GET /n8n/find/:instanceNameDELETE /n8n/delete/:id/:instanceName
Expected behavior: When a bot's enabled is false, the integration must NOT dispatch any HTTP call to webhookUrl.
Actual behavior: Message events continue to be POSTed to webhookUrl while enabled=false. Payloads look like MESSAGES_UPSERT events (body sizes 13–1845 bytes) and arrive at a steady rate of a few per minute, causing continuous 404 traffic when the target workflow/webhook is removed. Disabling the whole module (N8N_ENABLED=false) correctly makes the /n8n/* API routes return 400 {"message":["N8n is disabled"]}, and the outgoing flood only stops after the bot record itself is deleted.
Repro steps:
- Create an instance and connect WhatsApp.
POST /n8n/create with { "name": "bot1", "enabled": true, "url": "https://your-request-bin/webhook", "triggerType": "all", "listeningFromMe": true }.- Receive a message → a POST arrives at the webhook URL.
- Disable the bot (
POST /n8n/changeStatus/:id/:instanceName or set enabled=false in the record).
- Receive another message → a POST still arrives at the webhook URL (bug:
enabled=false is ignored in the event-dispatch path).
Notes: The N8N_ENABLED=false module-level guard works for the API routes; the per-bot enabled flag appears not to be honored (or is cached/stale) when dispatching events.
Summary: An n8n bot (integration) whose config has
enabled: falsekeeps sending HTTP calls to itswebhookUrlon incoming WhatsApp message events. On v2.3.7 we observed hundreds of POST requests per day to the bot'swebhookUrlwhile the bot record hadenabled = false; traffic only stopped after the bot record was deleted viaDELETE /n8n/delete/:id/:instanceNameand the module envN8N_ENABLED=falsewas in place.Environment: Evolution API v2.3.7 (Docker Swarm, PostgreSQL persistence, RabbitMQ events enabled).
Endpoints involved:
POST /n8n/create/:instanceName(bot config withenabledflag)POST /n8n/changeStatus/:id/:instanceName(enable/disable)GET /n8n/find/:instanceNameDELETE /n8n/delete/:id/:instanceNameExpected behavior: When a bot's
enabledisfalse, the integration must NOT dispatch any HTTP call towebhookUrl.Actual behavior: Message events continue to be POSTed to
webhookUrlwhileenabled=false. Payloads look likeMESSAGES_UPSERTevents (body sizes 13–1845 bytes) and arrive at a steady rate of a few per minute, causing continuous 404 traffic when the target workflow/webhook is removed. Disabling the whole module (N8N_ENABLED=false) correctly makes the/n8n/*API routes return400 {"message":["N8n is disabled"]}, and the outgoing flood only stops after the bot record itself is deleted.Repro steps:
POST /n8n/createwith{ "name": "bot1", "enabled": true, "url": "https://your-request-bin/webhook", "triggerType": "all", "listeningFromMe": true }.POST /n8n/changeStatus/:id/:instanceNameor setenabled=falsein the record).enabled=falseis ignored in the event-dispatch path).Notes: The
N8N_ENABLED=falsemodule-level guard works for the API routes; the per-botenabledflag appears not to be honored (or is cached/stale) when dispatching events.