ERR_N8N_WEBHOOK_INVALID on n8n: n8n webhook signature invalid — an incoming webhook is rejected because the computed signature does not match the signature sent by the source service. Root cause: Webhook signature validation fails when n8n calculates an HMAC from bytes that differ from the bytes signed by the source service. Typical causes are using the parsed JSON body instead of the raw request body, selecting the wrong HMAC algorithm, encoding the secret incorrectly, reading the signature from the wrong header, or letting a reverse proxy alter the request. The secret itself may be valid; the comparison fails because one side signs a different representation of the payload. Step 1: Record the signature header, algorithm, and source documentation. Open one rejected execution and capture the signature header name exactly as received, such as X-Hub-Signature-256 or Stripe-Signature. Then check the sending service documentation for the algorithm, the signed payload format, and whether the timestamp is included. Do not compare only the signature value; the header may carry a version prefix or multiple signatures that need parsing before verification. Step 2: Preserve the raw request body before JSON parsing. HMAC validation must use the original request bytes. Re-serialising a parsed JSON object changes whitespace, field order, escape sequences, or Unicode encoding and produces a different digest. Configure the n8n webhook or your fronting service to retain the raw body, then pass that raw string or buffer into the Code node. Use the parsed JSON only after the signature has been validated. Step 3: Recreate the source HMAC in a Code node with the correct encoding. In a Code node, calculate the digest using the exact algorithm named by the source, most commonly SHA-256, the raw body, and the unmodified signing secret. Output the resulting hexadecimal or base64 digest in a test execution and compare it with the received header after removing any documented prefix. Keep the secret in n8n credentials or an environment variable; never place it in a workflow field that can be exported with the workflow. Step 4: Check timestamp tolerance and replay protection. Some providers sign a timestamp together with the payload. If the server clock is inaccurate or an event was retried long after it was generated, a valid HMAC can still be rejected by the timestamp tolerance. Ensure the n8n host uses reliable time synchronisation, parse the provider timestamp correctly, and allow only the documented tolerance. Store event IDs or delivery IDs so a valid signature cannot be replayed indefinitely. Step 5: Rule out reverse-proxy body changes. If n8n is self-hosted behind Nginx, Cloudflare, or another proxy, compare a request captured at the edge with the request n8n receives. Disable transformations such as automatic decompression, body rewriting, or character-set conversion for the webhook route. Also verify the proxy permits the full request size; a truncated body produces a signature mismatch that looks like a secret problem. Step 6: Test with a provider-generated event and enable only safe logging. Use the sender’s test-webhook facility to generate a new signed event, then verify the signature before allowing the downstream workflow to execute. Log the event ID, algorithm, body length, and validation result, but never the secret or full personal-data payload. Once the test passes, turn on the production workflow and monitor the first live deliveries for signature failures or duplicate event IDs.