Quick Answer
A webhook signature verification checklist should confirm the sender secret, preserve the raw request body, read the correct signature header, compute the expected signature with the documented algorithm, compare signatures safely, reject stale or mismatched requests, and log enough delivery evidence for replay decisions. For content operators using GitHub, Slack, Stripe, n8n, WordPress, or no-code workflow tools, the best fit is to verify the request before any draft, spreadsheet row, Slack alert, source note, or publishing handoff is created.
Verification Decision Matrix
| Checkpoint | GitHub signal | Slack signal | Stripe signal | Operator decision |
|---|---|---|---|---|
| Shared secret | Webhook secret token | App signing secret | Endpoint signing secret | Store outside article files and repo code |
| Raw body | Payload contents used for HMAC | Raw body before parsing | Raw request body for event construction | Verify before JSON or form mutation |
| Header | X-Hub-Signature-256 | X-Slack-Signature plus timestamp | Stripe-Signature | Reject missing or unexpected headers |
| Algorithm | HMAC SHA-256 | HMAC SHA-256 over version, timestamp, body | Stripe library or documented signature check | Match the provider docs exactly |
| Replay window | Delivery log and troubleshooting evidence | Timestamp freshness check | Endpoint secret and event test flow | Treat stale requests as review items |
| Response rule | Respond quickly or queue work | Reject failed signatures | Return a failure status for bad signatures | Verify first, queue second, process third |
Who Should Use This Checklist?
Use this checklist when an operator accepts webhook events from GitHub, Slack, Stripe, n8n, WordPress-adjacent automations, or similar tools into a content workflow. It fits source-intake forms, repository events, editorial task creation, spreadsheet updates, notification workflows, and draft handoffs. It is not a penetration test, legal compliance review, payment-processing guide, or security certification.
The practical problem is simple: a webhook URL can be called by an outside system, but the receiving workflow still needs a way to decide whether the request came from the expected sender and whether the payload changed in transit. A source-aware operator should make that decision before a webhook creates work that another person trusts.
This article is source-derived analysis from official docs. It does not claim that Yolkmeet inspected private GitHub deliveries, Slack apps, Stripe event destinations, n8n instances, WordPress endpoints, secrets, logs, or production webhook payloads.
Step 1: Classify The Webhook Before Adding Verification
Start by naming the webhook's job. Signature verification is easier when the operator knows the consequence of accepting a request.
- [ ] Record the sender: GitHub, Slack, Stripe, n8n, WordPress route, or another product.
- [ ] Record the destination: spreadsheet row, content database, notification, source note, task, queue item, or draft.
- [ ] Record whether the event can create, update, delete, publish, notify, or bill anything.
- [ ] Record the provider's documented verification method and header names.
- [ ] Record whether the receiving tool can access the raw request body.
- [ ] Record the reject behavior for missing headers, stale timestamps, wrong secrets, malformed payloads, and duplicate deliveries.
The best choice is to keep high-consequence webhooks behind a review queue. A signed webhook can still carry bad data, duplicate data, or an event the team is not ready to process. Signature verification answers "who sent this request and was the body preserved?" It does not answer "should this become public content?"
Step 2: Preserve The Raw Request Body
Raw body handling is the first technical checkpoint. Several webhook providers compute signatures over the exact request body. If middleware parses JSON, reorders fields, changes encoding, or converts form data before verification, the expected signature may no longer match.
Use this raw-body checklist:
- [ ] Capture the raw request body before JSON, form, or multipart parsing.
- [ ] Avoid rewriting whitespace, character encoding, field order, or byte content before verification.
- [ ] Store only minimal metadata in public notes; do not paste private payloads into article drafts.
- [ ] If a no-code tool cannot expose the raw body needed by the provider, route the request through a small verification endpoint first.
- [ ] Verify first, then normalize the payload into the internal workflow shape.
GitHub documentation ties the signature to the payload contents and warns that proxies or load balancers should not modify payloads or headers before verification. Slack documentation also depends on the raw request body and timestamp when building the signature base string. Stripe examples use raw request middleware before constructing the verified event. The operator rule is to keep verification at the edge of the workflow, before convenience parsing.
Step 3: Match The Provider Header And Algorithm
Do not invent a generic webhook signature rule. Match the provider's documented header and algorithm.
| Provider | Verification surface | Better choice |
|---|---|---|
| GitHub | Secret token plus X-Hub-Signature-256 | Prefer the SHA-256 header and compare safely |
| Slack | Signing secret, timestamp, raw body, X-Slack-Signature | Reject old timestamps before processing |
| Stripe | Raw body, Stripe-Signature, endpoint secret | Use the official library or documented endpoint secret flow |
| n8n | Webhook node authentication options | Use Basic, Header, JWT, or an upstream verifier as appropriate |
| WordPress-adjacent custom routes | Route permissions and external sender docs | Verify before invoking any content operation |
For GitHub, the important operator detail is that the more secure current header is X-Hub-Signature-256, and the expected value is built from the secret token and payload contents. For Slack, the signing process includes a request timestamp, which supports replay protection when the receiver checks freshness. For Stripe, the handler uses the signature header and endpoint secret with the raw request body. For n8n, the Webhook node documents authentication choices such as Basic auth, Header auth, JWT auth, or none; use those deliberately and add a verifier when the sender requires a provider-specific signature.
Step 4: Reject Before Any Downstream Work
Verification should happen before the workflow creates work. A bad request should not create a draft, task, row, alert, content idea, or publishing payload.
- [ ] Missing signature header: reject and log only safe metadata.
- [ ] Missing or unknown secret: reject and route to owner setup.
- [ ] Signature mismatch: reject without normalizing the payload.
- [ ] Stale timestamp or replay suspicion: reject or hold for operator review.
- [ ] Correct signature but unsupported event type: acknowledge only if the provider expects it, then ignore or route to review.
- [ ] Correct signature and supported event type: queue the normalized record for the next workflow step.
This order protects content operations from invisible chains. For example, a GitHub repository event can become a source-update task. A Slack slash command can become a triage note. A Stripe event can trigger a business workflow. An n8n webhook can start a broader automation. None of those should proceed until the sender check passes.
Step 5: Keep A Verification Evidence Log
The evidence log should be useful without exposing secrets or private payloads.
| Evidence field | What to record | What not to record |
|---|---|---|
| Provider | GitHub, Slack, Stripe, n8n, or other | Secret value |
| Event name | Push, slash command, event type, or workflow path | Full private payload |
| Delivery ID | Provider delivery or request ID when available | Access token |
| Verification result | Passed, missing header, mismatch, stale timestamp | Signature secret |
| Destination decision | Rejected, held, queued, ignored, processed | Raw sensitive fields |
| Owner | Person or workflow responsible for follow-up | Personal credentials |
Pair this with source-notes-workflow-for-blog-posts when the webhook creates research evidence. Pair it with automation-error-handling-checklist when mismatches or stale requests repeat. Pair it with no-code-automation-rate-limit-checklist when valid requests arrive too quickly for the destination workflow.
Step 6: Separate Verification From Authorization
A valid signature means the request came from the expected sender and the payload matched the signed body. It does not mean every event should be allowed to do every action.
Add an authorization layer after verification:
- [ ] Allow only the event types the workflow actually needs.
- [ ] Map event types to specific downstream actions.
- [ ] Require manual review before public WordPress publishing, destructive changes, account changes, or external notifications with business consequences.
- [ ] Add a dedupe key before creating rows, tasks, or drafts.
- [ ] Keep publish-adjacent automations behind editorial approval and queue gates.
This is especially important for WordPress and content operations. A signed webhook can safely create a draft review item, but it should not bypass source checks, originality gates, SEO/AEO/GEO readiness, or policy review.
What Should A Webhook Signature Verification Checklist Include?
A webhook signature verification checklist should include the sender, destination, shared secret owner, raw body handling rule, signature header, algorithm, timestamp or replay window, reject behavior, safe evidence log, event allowlist, dedupe key, and downstream authorization rule.
The practical order is: classify the webhook, preserve the raw body, compute or delegate the provider-specific signature check, reject bad requests before processing, log safe evidence, then queue only the events the workflow is allowed to handle.
Common Questions
Is header authentication enough for every webhook?
No. Header authentication may be enough for simple internal tools, but provider-signed webhooks should use the provider's documented signature process when available. n8n supports several webhook authentication methods, while GitHub, Slack, and Stripe document signature-specific verification flows.
Should a verified webhook publish a WordPress post?
No. Verification is an intake control, not editorial approval. A verified request may create a draft note, queue item, source log, or operator task, but public publishing should remain behind source, originality, SEO/AEO/GEO, and policy gates.
Why do signatures fail when the secret is correct?
Common causes include using the wrong header, using the wrong endpoint secret, changing the body before verification, using the wrong algorithm, using a stale timestamp, or having a proxy modify headers or payloads. Check the provider troubleshooting docs before changing downstream workflow logic.
What should be logged after a failed signature check?
Log the provider, route, timestamp, delivery ID when available, reject reason, and owner. Do not log the secret, full raw body, personal data, payment details, private source payloads, or access tokens.
Where should no-code operators verify signatures?
Verify as close to the webhook edge as possible. If the no-code platform can access the raw body and required headers safely, verification can happen inside that workflow. If it cannot, use a small upstream endpoint to verify and forward only normalized, safe fields.
Source Notes
- https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries checked 2026-06-10; used for source-derived analysis of GitHub webhook secrets,
X-Hub-Signature-256, HMAC SHA-256, payload handling, secure comparison, and signature troubleshooting. - https://docs.github.com/en/webhooks/testing-and-troubleshooting-webhooks/troubleshooting-webhooks checked 2026-06-10; used for source-derived analysis of missing deliveries, delivery logs, response timing, failed signature verification, and queueing work after receipt.
- https://docs.slack.dev/authentication/verifying-requests-from-slack/ checked 2026-06-10; used for source-derived analysis of Slack signing secrets, raw body handling, timestamp freshness, signature base strings, and replay-aware verification.
- https://docs.stripe.com/webhooks checked 2026-06-10; used for source-derived analysis of Stripe webhook endpoint handlers, raw request body handling,
Stripe-Signature, endpoint secrets, HTTPS endpoint registration, and test listener behavior. - https://docs.stripe.com/webhooks/signature checked 2026-06-10; used for source-derived analysis of Stripe signature troubleshooting, endpoint secret mismatch, and payload handling risk.
- https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/ checked 2026-06-10; used for source-derived analysis of n8n Webhook node behavior, test and production URLs, supported HTTP methods, payload size, authentication choices, response modes, and webhook-triggered workflow boundaries.
No private GitHub webhook, Slack app, Stripe account, n8n workflow, WordPress endpoint, request log, secret, signature, payment event, customer record, source intake payload, or production automation was inspected for this article. If a future operator attaches request exports, delivery screenshots, verification logs, or controlled endpoint tests, update the claims to match that evidence.
Internal Link Notes
Link to webhook-intake-workflow when readers need the broader intake shape after sender verification. Link to automation-error-handling-checklist when failed verification or malformed payloads need repeatable recovery. Link to no-code-automation-rate-limit-checklist when valid signed requests arrive in bursts. Link to wordpress-rest-api-exposure-checklist when custom WordPress routes receive external events. Link to source-notes-workflow-for-blog-posts when verified requests become source evidence.
Update Note
Review this checklist every 60 days. Recheck GitHub validating and troubleshooting docs, Slack request verification docs, Stripe webhook and signature docs, and n8n Webhook node docs. Refresh earlier after a provider changes signature headers, endpoint secret handling, replay guidance, payload parsing requirements, authentication options, response timing, or webhook delivery troubleshooting behavior.