> For the complete documentation index, see [llms.txt](https://docs.contextual.io/documentation-and-resources/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.contextual.io/documentation-and-resources/components-and-data/flows/node-reference/network/http-in.md).

# 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](/documentation-and-resources/components-and-data/agents/types-of-agents/http-to-flow.md), 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](/documentation-and-resources/components-and-data/flows/node-reference/function/function.md) immediately after HTTP In:

```js
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](/documentation-and-resources/components-and-data/flows/node-reference/network/http-response.md) 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](/documentation-and-resources/components-and-data/flows/message-object.md#http-request-messages) 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](/documentation-and-resources/components-and-data/flows/node-reference/common/link-call.md) 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.contextual.io/documentation-and-resources/components-and-data/flows/node-reference/network/http-in.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.