Webhook signature verification answers a question that a successful connection test cannot: did this request come from the expected sender, without its signed content being altered? A public endpoint may receive traffic from anyone who knows its address. A working URL alone does not establish trustworthy business events.
For a small business, the consequence can be a false order update, an unauthorized workflow, or repeated processing after a retry. This guide gives administrators and developers a practical receiver checklist. It does not provide a universal signature formula, because each provider defines its own signing contract and delivery behavior.
Quick answer: verify before doing business work
Use the sender’s documented verifier with the original request body, required signature headers, and the correct endpoint secret. Reject requests that fail verification before they change business records. After verification, preserve accepted work reliably, acknowledge it appropriately, and process it with duplicate protection. Signature checking and duplicate protection solve different problems.
Key takeaways
- A receiver URL is not an authentication credential.
- Verify the original body before parsing or transforming it.
- Provider-specific headers and timestamp rules are not interchangeable.
- A valid signature does not make repeated business actions safe.
Distinguish the URL, API key, and signing secret
The webhook URL is the destination where a sender delivers events. Your website, integration platform, or application provides that address. The URL should point to an authorized receiver you control, not to an arbitrary testing service that would expose customer information. Its availability tells you where requests go, not whether they are genuine.
An API key usually authorizes an application to call a provider’s API. A webhook signing secret is used to verify inbound deliveries under that provider’s protocol. Do not substitute one for the other simply because both are long strings. Check the provider’s endpoint settings and documentation to identify the specific secret required.
Some providers generate an endpoint signing secret; others let the webhook owner configure one. For example, GitHub’s validation guide describes configuring a high-entropy secret and securely storing it on the receiver. The administrator should follow the provider’s setup rather than inventing a shared password or reusing a website login credential.
Keep production and testing configurations separate. Record an endpoint identifier, environment, responsible owner, and secret version identifier without recording the secret itself in a shared spreadsheet. Store the actual value in an approved secret-management location. A support conversation should refer to the version, not reveal the credential to prove that it exists.
If a WordPress plugin asks for a webhook URL and signing secret, confirm that its documented signing format matches the destination’s verifier. Two applications both advertising “webhook support” do not necessarily speak the same protocol. The receiving developer may need to implement an adapter or select a supported integration rather than paste unrelated credentials.
A receiver checklist for trustworthy events
1. Preserve the original body
Ask the developer where the application obtains the request bytes and whether middleware changes them first. Parsing JSON and serializing it again can change whitespace or representation even when the business values look identical. A verifier needs the signed representation, not a reconstructed object that happens to contain similar fields.
Review the full inbound path, including a proxy, gateway, and application framework. The owner should demonstrate that the required headers and body reach verification intact. Treat this as an implementation contract and include it in release tests. Otherwise, a routine framework change can silently break a receiver that previously worked.
2. Select the verifier for the actual sender
Prefer the provider’s maintained library or documented implementation for your runtime. Record the library and version in the implementation notes. Avoid hand-written cryptography when a supported verifier already exists. A copied example from a different sender can look convincing while applying the wrong input format, algorithm, or freshness checks.
Before accepting an event, require the expected header and the correct secret configuration. Do not fall back to trusting a request because its JSON contains a plausible product name. The contents of an unverified request are attacker-controlled. Routing a request to a particular handler is not itself evidence of its origin.
3. Separate acceptance from downstream work
Our recommended architecture is to verify, validate the minimal event envelope, reliably preserve the accepted task, then acknowledge and process it. A durable queue or equivalent record can separate quick inbound handling from slower business work. This is an architectural recommendation, not a promise that every plugin provides those components automatically.
Define what happens if preservation fails. Returning success while silently losing the task makes the sender believe delivery completed. Conversely, repeating expensive business processing inside a slow request can create timeouts and ambiguous results. The developer should document the acknowledgment boundary and demonstrate failure behavior in a non-production environment.
| Stage | Evidence to request | Unsafe shortcut |
|---|---|---|
| Receive | Original body and required headers preserved | Verify transformed JSON |
| Authenticate | Provider verifier accepts valid fixtures | Trust a product name in the payload |
| Preserve | Accepted task has a durable record | Acknowledge work that was lost |
| Process | Repeated delivery does not repeat effects | Assume valid signatures prevent duplicates |
Stripe and GitHub illustrate different signing contracts
Stripe’s webhook documentation describes verification using the unchanged body, the Stripe-Signature header, and the endpoint signing secret. Its supported libraries also check the signed timestamp; the default tolerance is five minutes. Setting tolerance to zero disables that recency check rather than making it stricter. Keep the receiver’s clock synchronized.
GitHub uses X-Hub-Signature-256 with an HMAC-SHA256 signature that begins sha256=. Its documentation recommends a constant-time comparison instead of ordinary equality. Do not apply Stripe’s header layout or timestamp expectation to GitHub. Follow the documented contract for the configured sender and keep its test fixtures alongside the receiver implementation.
These examples explain why a generic “signature verified” label needs context. Ask which provider contract was checked, with which endpoint configuration, and which tests passed. A settings page displaying a nonempty secret is useful configuration evidence, but it does not prove the deployed handler actually uses that value correctly.
Do not infer broader privileges from an authenticated event. The handler should still recognize supported event types, validate required identifiers, and apply the application’s business rules. An authentic event for one account should not automatically authorize changes to a different customer’s records. Keep authentication, event interpretation, and business authorization as separate review questions.
For teams choosing an automation platform, Daily Jade’s n8n versus Zapier comparison discusses broader workflow choices. However, selecting a tool does not eliminate the need to review its inbound authentication behavior. Verify the particular node, connector, and receiver path you actually deploy, not the platform name alone.
Test webhook signature verification without real customer data
Build a small fixture suite in an authorized test environment. Use provider-supported test events or synthetic records that cannot trigger real fulfillment, payments, or customer messages. The expected result should describe both the HTTP outcome and the business outcome. A rejected request is not a passing test if it already changed a record.
Start with a correctly signed request using the test endpoint’s own configuration. Confirm that it reaches the accepted-work record and follows the intended workflow exactly once. Then change one body byte without changing the signature. The altered request should fail verification and produce no business action. Preserve the result as a regression test.
Next test a missing signature header and a request checked against the wrong test secret. Confirm that neither takes an alternate unauthenticated path. Do not place real secrets in fixture files, screenshots, or exception messages. A fixture generator can read an approved testing secret securely without storing it in the project repository.
Test freshness only according to the provider’s documented protocol. For a timestamped signing system, check an old signed request and a receiver with the correct clock. Do not invent an arbitrary age limit for a sender that does not include a comparable signed timestamp. Request age and duplicate business processing are related operational concerns, not interchangeable controls.
Finally, deliver the same valid business event again. Verification may correctly succeed on another authentic delivery. Your processing logic must still avoid repeating the protected effect. Demonstrate that duplicate detection records the repeat and leaves the order, subscription, or notification state correct. A second successful signature check does not justify a second shipment.
Plan for retries, rotation, and observable failures
Document the event identity used for duplicate protection and the operation it protects. An event identifier and a business identifier can serve different purposes. Two different authentic events may refer to one order, while one event may be retried several times. Define how the worker handles each case instead of relying on a blanket “seen this customer” filter.
Keep authentication failures separate from worker failures in monitoring. Log a sanitized failure category, endpoint identifier, time, and safe correlation reference. Avoid logging whole payloads or signature headers by default. The operational question is whether a request was rejected, accepted, queued, or completed; exposing credentials is not necessary to answer it.
If the receiver times out after a downstream write, review destination state before retrying the business operation. A network failure does not establish that the write failed. Daily Jade’s Zapier versus Make guide provides platform context, while the GitHub versus GitLab comparison can help teams organize versioned implementation and release review.
Rotate signing secrets using the provider’s current procedure. Do not assume every service supports two active secrets or the same overlap period. Record which endpoint and environment changed, deploy the compatible verifier configuration, and validate authorized test deliveries. If verification fails after rotation, investigate the configuration mismatch rather than disabling authentication as a temporary fix.
Assign ownership before production rollout. Someone should respond to rising rejection counts, stalled accepted tasks, and duplicate-effect alerts. Include a rollback plan that preserves security and an escalation path to the provider. A webhook that passes setup once still needs maintenance when frameworks, credentials, or connected applications change.
FAQ and final receiver review
Does HTTPS replace a signing secret?
No. Transport protection and sender verification address different questions. A publicly reachable HTTPS endpoint can still receive requests from an unauthorized caller. Use the provider’s supported authentication method and review the receiver’s processing behavior. Do not treat a padlock or an accessible URL as evidence that incoming business events are authentic.
Can I use one signing format for every vendor?
Not safely without an adapter that explicitly implements each vendor’s contract. Headers, signing inputs, secret setup, and timestamp behavior differ. Maintain separate tested verifier paths for supported senders. Reject an unsupported format instead of guessing which algorithm might make its contents appear valid.
What proves the receiver is ready?
Look for verified valid fixtures, rejected altered and unsigned requests, reliable accepted-work preservation, and repeated deliveries that do not repeat business effects. Review logs for credential exposure and assign an operational owner. These checks establish more than a green connection indicator because they examine the complete acceptance and processing boundary.
Final recommendation
Implement webhook signature verification as an explicit gate, then test the surrounding workflow separately. Preserve original bytes, use the sender’s documented verifier, and protect business actions against repeats. If the signing contract or endpoint ownership is unclear, keep the integration disabled until the responsible administrator and developer can establish it safely.
Last reviewed: October 9, 2026. This is an implementation checklist, not a security certification or a substitute for provider-specific review.
Join the conversation
Share a useful perspective, question, or first-hand experience with other Daily Jade readers.