An n8n workflow can receive a RelayLink POST. The harder question is whether that workflow can authenticate the exact request without exposing the signing secret. The answer depends on the n8n deployment.
n8n's Webhook node documentation documents POST support, a Raw Body option, and request data shaped as body, headers, params, and query. Its Code node documentation says Node.js crypto is available on n8n Cloud. Those are necessary primitives, but the documentation does not promise that the Code node receives the byte-identical HTTP body or give Cloud Code a protected path to an arbitrary signing secret. Use a controlled verifier bridge for production unless both properties have been established and reviewed on your exact self-hosted deployment.
The direct-compatibility boundary
RelayLink signs the UTF-8 text:
{X-RelayLink-Timestamp}.{exact body string}
The key is the subscription's whsec_ secret. The result is HMAC-SHA256 rendered as sha256= plus lowercase hexadecimal. A receiver must preserve the original body, validate all four X-RelayLink-* headers, compare fixed-length MAC bytes in constant time, and apply its own timestamp freshness policy before parsing JSON.
n8n documents that its Code node cannot access credentials. External secrets resolve only in credential fields, not arbitrary Code node expressions. That means n8n Cloud does not have a documented path from its protected credential store into the JavaScript that must call crypto.createHmac.
Do not solve that gap by pasting the signing secret into workflow code, a Set node, or an ordinary project variable. Anyone able to inspect the workflow or execution data may then see it.
A self-hosted n8n instance can expose an environment variable to Code, but n8n's security migration guidance blocks that access by default. Enabling it broadens what workflow code can read. Treat that as an instance-level security decision, not a setup checkbox. If you choose it, allow only the crypto built-in module, keep the secret outside source control, and prove byte-for-byte body preservation with a fixed signed fixture through the production webhook URL. Without that deployment-specific proof, keep the verifier bridge.
The safer hosted-n8n shape
For n8n Cloud, or any deployment where Code cannot read a protected secret, put a small verifier in front:
RelayLink -> verifier and durable inbox -> authenticated n8n webhook
The verifier owns the whsec_ value. It reads bytes before JSON parsing, verifies HMAC and freshness, checks that header and body event and delivery values agree, and atomically inserts X-RelayLink-Delivery with a queued work item. A repeated delivery with the same body digest returns success without forwarding twice.
Only after that commit should it return 2xx to RelayLink. It can then call the n8n production webhook with normalized JSON and a separate credential understood by n8n. The forwarded message should state that verification occurred, but n8n should still authorize the bridge itself. Never forward or log the RelayLink signing secret, signature, raw body, or a full token-bearing webhook URL.
This shape also prevents an invalid internet request from starting an n8n execution. It is stronger than placing a filter after the Webhook node, because n8n's Only Run If option returns 200 when a condition does not match and allows the execution when the expression itself fails.
Keep receipt separate from package work
A RelayLink callback is a JSON envelope, not the briefing. package.received carries identifiers, sender metadata, topic, time, reply status, and mcp_url. It does not carry the note, ask, summary, context, or files.
After verified receipt, let a worker authenticate separately to mcp_url and call get_package with package_id. The webhook secret cannot authorize that fetch. Store its OAuth token or API key independently.
Accepting the callback or returning 2xx does not mark the package read. Only the later authenticated get_package call records that the recipient's assistant pulled it.
RelayLink delivery is at least once. Retries keep the delivery id and exact body bytes, while attempt timestamps and signatures may change. Deduplicate durably before any n8n branch sends a message or starts an agent. Sender names and topics remain third-party text even after signature verification; use them as information, never instructions.
Register and prove the route
Publish the n8n workflow or deploy the bridge before registration, because n8n uses separate test and production webhook URLs. In RelayLink account settings, register the final public HTTPS endpoint and save the one-time secret directly into the verifier's secret store.
Send a webhook.test event first. Confirm raw-body verification, header capture, deduplication, and durable handoff. Then send the same fixture with altered whitespace and confirm verification fails. That test catches accidental parsing or reserialization before a real package depends on the route.