HTTP In

Creates an HTTP endpoint for flows that need to receive web requests.

Use HTTP In nodes to define the inbound paths and HTTP methods for a flow. This is the standard entry point for HTTP to Flow agents when you are building a webhook, a REST API, or simple web content.

Request bodies and webhook signatures

For a JSON POST handled by a deployed HTTP to Flow agent, the incoming message has two distinct representations of the body:

• msg.payload and msg.req.body contain the parsed JSON at the HTTP In node's output.

• msg.req.rawBody contains the Buffer captured by the runtime's JSON parser before JSON parsing. It is not a JSON object or a reconstructed string.

When a webhook provider requires a signature over the request body, use the preserved buffer with the provider's verification procedure. Do not substitute JSON.stringify(msg.payload) or JSON.stringify(msg.req.body): parsing and serializing can change whitespace, escaping, and other details that affect a signature.

Check availability in the target runtime

The Flow Editor and a deployed HTTP to Flow agent run in different hosts. Do not assume their request middleware is identical: a missing msg.req.rawBody in an editor test does not establish that it is unavailable in the deployed agent. Test the actual endpoint and request content type you will use.

For a non-sensitive test request, place this Function immediately after HTTP In:

msg.hasRawBody = Boolean(msg.req && Buffer.isBuffer(msg.req.rawBody))
return msg

Inspect only msg.hasRawBody, not the complete message. The example preserves the original message and does not log or return the body to the caller. It checks availability only; it does not verify a signature.

An empty request body produces a zero-length Buffer, so the availability check above still returns true. If the webhook provider requires a non-empty body, check msg.req.rawBody.length separately and reject an empty body before signature verification so it can be reported distinctly from a signature mismatch.

If msg.req.rawBody is unavailable where signature verification requires it, reject the request through an appropriate HTTP Response path before processing the webhook. Do not silently skip verification or fall back to re-serializing parsed JSON. Keep raw bodies, signature headers, and signing secrets out of diagnostic logs.

Scope and limitations

• This capture belongs to the deployed runtime's JSON-parser path, not every HTTP In request. Do not assume it applies to multipart uploads, URL-encoded forms, plain text, or every JSON-related media type.

• Parser limits and errors still apply. A malformed, oversized, or unsupported request may be rejected before reaching the flow.

• The buffer is the body presented to the JSON parser, not a universal capture of the exact bytes transmitted over the network. Decompression or upstream processing can change that representation. Validate compressed requests and any other encoding requirements against the webhook provider's signing specification before relying on them.

• Preserve msg.req and msg.res as the message moves through the flow. See the Message Object reference.

Path parameters

HTTP In path syntax follows the Express-style route parameter syntax used by Node-RED, such as /weather-report/:reportId. In the flow, those values are available on msg.req.params.

Routing caveats

Avoid overlapping paths that depend on route order.

For example, these two routes can conflict:

• /path1/subpath1

• /path1/*

Unlike a hand-written Express app, you should not assume the more specific route will always win. Matching can depend on the order of the entry nodes in the resulting flow JSON, and that order is not something you can reliably control.

Recommended approach

To keep HTTP flows predictable:

• Prefer mutually exclusive paths whenever possible.

• If you need a catch-all route, exclude the prefixes handled by your more specific routes so the wildcard never overlaps with them.

• If multiple entry points should do the same work, send them into shared downstream logic with Link Call instead of duplicating the processing path.

For example, if /api, /ws, and /_old each have their own HTTP In node, a catch-all path like this excludes those prefixes:

/:fullpath((?!api/?)(?!ws/?)(?!_old/?)(*))

This matches any path that does not start with /api, /ws, or /_old, stores the remainder in msg.req.params.fullpath, removes the overlap entirely, and avoids depending on route precedence.