How Do You Verify Webhook Signatures in a No-Code Automation?

Why should a no-code automation verify webhook signatures?

Because a webhook URL is just a public address. Anyone who finds it can send a request that looks like a real event. Without verification, your automation might create fake leads, change CRM records, or trigger emails from a forged request. A signature check confirms that the event really came from the sender and was not changed on the way.

Most no-code builders never think about this. They create a webhook trigger in Zapier, Make, or n8n, paste the URL into another tool, and move on. That works until the URL leaks through a screenshot, a shared doc, or a former contractor, and someone starts sending junk.

Stripe's documentation puts the risk plainly: without verification, an attacker could send fake webhook events to your endpoint to trigger actions such as modifying records. For revenue automations that write to your CRM, that is not a theoretical concern.

What is a webhook signature?

A webhook signature is a code the sender calculates from the request content and a shared secret, then sends in a header. Your automation repeats the same calculation with the same secret. If the two results match, the request is genuine and unchanged. If they do not match, you reject it.

The common method is an HMAC, usually with SHA-256. Webflow's developer documentation, for example, says its x-webflow-signature header is formatted as a SHA-256 HMAC hash, and that the signed content is the timestamp and the request body joined with a colon. Stripe uses its own Stripe-Signature header with a similar idea.

You do not need to understand the cryptography to use it. You need three things: the secret, the exact request body, and a step in your automation that can compute an HMAC and compare it.

Do all webhooks come with signatures?

No. It depends on the sender and sometimes on how the webhook was created. Webflow's developer docs say webhooks created through the dashboard do not include the headers needed to validate signatures, while webhooks created through the API with a site token or an OAuth app do. Always check the sender's docs before assuming a signature exists.

Webflow's docs add detail on secrets. Webhooks created through an OAuth app use the app's client secret as the signing key. Webhooks created with a site token after April 14, 2025 each get their own secret key. Those details matter, because using the wrong secret is the most common reason verification fails.

If you set up a Webflow form webhook through the dashboard, as in my tutorial on sending Webflow form submissions to n8n, there is no signature to check. For a basic lead form, that is often acceptable. For anything that touches money or permissions, create the webhook through the API so you can verify it.

How do you verify a signature in n8n, Make, or Zapier?

Add a step right after the webhook trigger that computes the HMAC of the raw request body with your secret, then compare the result with the signature header. If they match, continue. If not, stop the run and log it. Most tools offer a crypto or code step for this, so check your tool's documentation for the exact option.

The details vary by sender. Some sign only the body. Others, like Webflow, sign the timestamp and body together. Read the sender's docs and build the exact string they describe. A single extra space or a different order will produce a different hash and a failed check.

Put the comparison in a clear IF or filter step with a descriptive name, such as "Signature valid". That makes the workflow readable, and it shows anyone reviewing it that verification is in place.

Why does the raw request body matter?

Because the signature is calculated on the exact bytes the sender sent. If your automation tool parses the JSON and then turns it back into text, spacing or key order can change, and the hash will not match. Stripe's documentation warns that the request body must be the exact string it sent, without modifications.

This is the part that trips up no-code builders most. Many webhook triggers parse the body for you, which is convenient for mapping fields but bad for verification. Look for an option in your trigger to keep the raw body available alongside the parsed data.

If your tool cannot provide the raw body, verification may not be reliable there. In that case, consider receiving the webhook in a small serverless function that verifies it and then forwards the trusted event to your automation.

How do you stop replayed requests?

Check the timestamp. If the sender includes one, reject any request older than a few minutes. Webflow's documentation says a request older than 5 minutes may indicate a replay attack and should be treated as potentially compromised. This stops someone from capturing a genuine request and resending it later.

Replay protection pairs well with duplicate protection. Even a genuine, recent event can arrive twice because of retries. Logging event IDs and skipping ones you have seen handles that case. I covered the duplicate side in detail in my piece on idempotent webhook retries.

Together, the three checks form a simple gate. The signature proves the sender. The timestamp proves it is fresh. The event ID proves you have not processed it already.

Where should you store the webhook secret?

Store it in your automation tool's credential or variable storage, never in plain text inside a step, a shared doc, or a chat message. Limit who can see it. Treat it like a password, because anyone who has it can forge valid requests to your automation.

Give each integration its own secret where the sender allows it. If one leaks, you replace that one without touching the others. This is the same principle I described in giving an agent the narrowest credential that works.

Plan for rotation. Stripe's docs recommend rolling signing secrets periodically or when you suspect a leak. My guide on rotating API keys without breaking your Zaps covers how to swap credentials without downtime.

What should happen when a signature check fails?

Stop the run, return an error status if your tool allows, and log the failure with the time and a short reason. Do not process any part of the event. If failures appear suddenly and in volume, alert a human, because that pattern can mean someone found your URL or a secret changed without the automation being updated.

Occasional failures usually have boring causes. The secret was rotated, the body was modified by a parsing step, or the signed string was built in the wrong order. A clear log entry makes those easy to diagnose.

Never add a "skip verification if it fails" fallback to keep things running. That turns your security check into decoration.

What should you do next?

List every webhook trigger in your automation stack and note whether the sender supports signatures. For those that do, add a verification step using the raw body and the correct secret, plus a timestamp check if one is provided. Store secrets properly, log failures, and alert on spikes. Start with the automations that write to your CRM.

Verification is a small addition to each workflow, but it changes your automation from "anyone with the URL can drive it" to "only the real sender can". For systems that run your revenue operations, that difference is worth the half hour.

If you want help adding signature checks to your Zapier, Make, or n8n workflows, or auditing which webhooks in your stack are exposed, reach out. I am happy to take a look.