Blocking Webhooks POST Payloads (Whapi.cloud) on Production URL - Empty Payload
chconza-sys
PROOP

4 months ago

Dear Railway support team,

I'm running an n8n (or PHP) automation application on my Railway service (datix.cloud) that is designed to receive WhatsApp Webhooks (Whapi.cloud) through HTTP POST requests.

We have identified a persistent problem where requests arrive at the application, but the payload is silently discarded, resulting in an application error:

Technical Details of the Problem

1. Connection and Method: The connection is successful (200 OK) to the production URL (https://flow.datix.cloud/webhook/...), confirming that the host and SSL are valid. The method used by the source service (Whapi.cloud) is POST.

2. Payload failure: The application does not receive the body of the request.

• In PHP: The file_get_contents('php://input') function returns an empty string.

• In n8n: The Webhook receives the event, but the $json object of the body payload is empty or incomplete.

3. Diagnostic: This suggests that the proxy layer or the WAF (Web Application Firewall) is inspecting and discarding the POST payload before it reaches my application, possibly due to a generic security rule or a poor Content-Type match.

Request for Permits

I request that you review the firewall or proxy configuration for my host (datix.cloud or the production URL of my instance) and:

• Check the WAF rules to prevent the payload of POST requests addressed to the path /webhook/ from being discarded.

• Allow the complete reading of the body of POST requests without modifying the payload (Raw Body) so that my PHP/n8n application can process the WhatsApp JSON.

I appreciate your prompt attention, since this problem is critical for the functionality of my chatbot in production.

Solved$10 Bounty

Pinned Solution

chconza-sys
PROOP

4 months ago

I found the problem was an infrastructure flaw in the Railway template, not an error in the logic or code.

🔑 The Cause of the Blockage: The Inactive Worker
The problem of the webhook not working in either test or production mode was the inactive worker.

Railway Templates and Server: Railway templates, while practical, often require multiple components. For n8n in Railway, there are two essential services:

Primary (the front-end and webhook listener): Handles the URL and the interface.

Worker (the back-end and task executor): Performs the heavy lifting (running the nodes, waiting for Gemini responses, managing the queue).

The Execution Failure: When the worker was inactive, the primary component received the webhook request but couldn't pass the task anywhere for processing. Therefore, the webhook was either canceled or remained in the queue.

The failed or inactive deployment of the worker was the bottleneck causing all the "Cancelled" errors and the inability to view the data.

Thank you for everything.

2 Replies

4 months ago

This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.

Status changed to Open brody 4 months ago


4 months ago

Hey, Railway does not alter any sort of body payloads (WAFs). If the Webhook request is getting through, then it's clearly a code issue.


chconza-sys
PROOP

4 months ago

I found the problem was an infrastructure flaw in the Railway template, not an error in the logic or code.

🔑 The Cause of the Blockage: The Inactive Worker
The problem of the webhook not working in either test or production mode was the inactive worker.

Railway Templates and Server: Railway templates, while practical, often require multiple components. For n8n in Railway, there are two essential services:

Primary (the front-end and webhook listener): Handles the URL and the interface.

Worker (the back-end and task executor): Performs the heavy lifting (running the nodes, waiting for Gemini responses, managing the queue).

The Execution Failure: When the worker was inactive, the primary component received the webhook request but couldn't pass the task anywhere for processing. Therefore, the webhook was either canceled or remained in the queue.

The failed or inactive deployment of the worker was the bottleneck causing all the "Cancelled" errors and the inability to view the data.

Thank you for everything.

Status changed to Solved samgordon 4 months ago


Loading...