From Webhook to Worker: Operating the Workflow

n8n’s workflow graph becomes a production system when an outside request can select it, run it, wait for it, and receive a response without losing the state that connects those transitions. This chapter follows that lifecycle from webhook ingress through published-version selection, validation, response delivery, waiting, queue placement, worker execution, and persistence. The goal is practical judgment: to see which responsibilities remain with the main request-handling process, which move to workers, and which shared stores make the graph resumable rather than merely executable in one process.

A production request enters a published graph

A production webhook is not the same thing as a request sent to the editor while a workflow is being built. n8n first looks up the HTTP method and path, then loads the workflow version associated with live execution. Depending on the configured publication path, the source loads data through a publication service or through the workflow’s active version; either way, the live path constructs a workflow from the selected version’s nodes and connections rather than accidentally using an unsaved draft. This is a form of control-plane discipline: the graph that receives real traffic is chosen deliberately.

The request handler supplies the outer HTTP boundary. It rejects unsupported methods, handles CORS where relevant, and delegates the request to a webhook manager. The live webhook service resolves dynamic path parameters, identifies the start node, and builds the execution context. For ordinary webhook nodes it sanitizes n8n’s own authentication, browser, session, form, and chat cookies before the workflow sees the request. That filtering is not business logic and does not replace webhook authentication; it prevents credentials belonging to the n8n interface from becoming incidental input to a user-authored workflow.

The Webhook node then applies its own contract. It can authenticate the request, reject disallowed IPs, ignore bots, read JSON or raw/binary bodies, and place headers, parameters, query values, and the body into an input item. The node’s response mode determines whether it answers as soon as the request is received, waits for a later response node, or uses a streaming response. The production request therefore crosses at least three distinct boundaries: transport handling, webhook authorization and parsing, and ordinary graph execution.

That separation is useful when diagnosing a failure. A request can fail before a workflow starts because its method or path is unknown. It can be rejected by authentication or an IP policy. It can be accepted but produce an invalid or empty input shape. Or it can enter the graph and fail in a downstream node. Treating all of these as “the workflow failed” hides the transition at which the system lost control.

Streaming illustrates how ingress and execution meet. The Webhook node can send response headers and keep the connection open while a compatible node emits chunks. The request handler knows how to deliver a stream, while the execution context decides whether streaming is available for the current mode and has a handler to receive chunks.