Recommended Free Tools
Webhook authentication is provider-specific: some platforms sign request bytes with HMAC, while Google Chat authenticates inbound interaction requests with a bearer token. Verify each request using that provider’s documented input and format before triggering side effects; do not assume one platform’s procedure works for another.
This guide covers Slack, GitHub, Microsoft Teams outgoing webhooks, Google Chat interaction requests, and Telegram Gateway delivery reports. It is not an exhaustive guide to every chat platform. In particular, the methods below should not be applied to other services without checking their current documentation.
As an Amazon Associate I earn from qualifying purchases.
What webhook verification proves—and what it does not
A signature or token check helps establish that a request was produced by a party holding the expected secret or identity. It does not make the request safe to process: validate its contents, authorize the requested action, and avoid applying duplicate events. HTTPS protects the connection, but by itself does not authenticate a request as belonging to the provider named in its headers.
HMAC verification depends on the exact input bytes the provider specifies. Parsing JSON and serializing it again can change whitespace, key order, or Unicode escapes, causing a valid signature to fail. Preserve the raw request body until verification is complete whenever the provider signs the body.
How to verify a Slack webhook signature
Slack signs a versioned string that incorporates the request timestamp and body, using an app-specific signing secret. The signature arrives in X-Slack-Signature; the timestamp is in X-Slack-Request-Timestamp.
- Read and retain the raw request body, without parsing and re-encoding it first.
- Read the timestamp and signature headers. Reject missing or malformed values.
- Construct Slack’s versioned signature base string exactly as its documentation specifies, then calculate HMAC-SHA256 with the app’s signing secret.
- Compare the calculated signature with the supplied signature using a constant-time comparison.
- Reject requests whose signed timestamp falls outside your configured recency window, then parse and process the body only after verification.
Because the timestamp is included in the signed input, the check can help limit replay of old requests; it does not replace event-level duplicate handling. Slack recommends signing secrets rather than its deprecated verification tokens. Its signing-secret mechanism is used for request types including Events API, shortcuts, and slash commands.
Rank #2
How to validate a GitHub webhook signature
GitHub sends an HMAC-SHA256 digest in X-Hub-Signature-256, with the value prefixed by sha256=. Configure a high-entropy webhook secret and keep it on the server.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Capture the exact payload bytes GitHub sent. Do not calculate the digest over parsed JSON or a re-serialized body.
- Calculate HMAC-SHA256 over those bytes using the configured webhook secret.
- Format the expected value as GitHub specifies and compare it with
X-Hub-Signature-256using a constant-time comparison. - Reject a missing, malformed, or non-matching signature before acting on the event.
X-Hub-Signature is the legacy HMAC-SHA1 header; GitHub recommends SHA-256 instead. The HMAC scheme described here does not include a timestamp freshness field, so the signature alone does not establish that a delivery is new. Use a stable delivery or event identifier to prevent duplicate processing.
What is established for Microsoft Teams outgoing webhooks?
Microsoft’s outgoing-webhook documentation identifies SHA-256 HMAC authentication and provides validation code. The exact signed input, header encoding, and freshness behavior must be taken from the current Microsoft instructions; they are not interchangeable with Slack’s or GitHub’s constructions.
Use Microsoft’s validation sample for the outgoing-webhook type you have configured, preserving its specified request bytes and header handling. Do not substitute a generic “HMAC the JSON body” implementation unless the current Teams instructions explicitly specify that input. A valid HMAC check also does not, by itself, establish replay protection unless the documented construction includes a freshness mechanism.
How to authenticate Google Chat interaction requests
Google Chat authenticates inbound requests to an app’s HTTPS endpoint with an Authorization: Bearer token. This is request authentication, not an HMAC signature over the body.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Determine the authentication audience configured for the app’s endpoint.
- For an HTTP endpoint URL audience, verify the token as an ID token. For a project-number audience configuration, verify it as a JWT according to Google Chat’s instructions.
- If the app runs on Cloud Run or Cloud Functions, Cloud IAM can perform verification when the Chat service account is authorized as an invoker. A custom HTTP server can validate the token with Google’s API client libraries or JWT validation.
- Reject an invalid token with HTTPS 401; process the interaction only after successful verification.
Do not confuse inbound interaction requests with Google Chat incoming webhooks. Incoming webhooks are secret-bearing posting URLs used to send messages into a space; they are not the bearer-token authentication method for requests sent to an app.
How to verify Telegram Gateway delivery reports
Telegram Gateway sends delivery reports with X-Request-Timestamp and X-Request-Signature. The signature uses a derived key and a timestamp-plus-body input.
- Read the raw POST body and the timestamp header exactly as received.
- Derive the HMAC key by calculating SHA-256 of the Telegram Gateway API token.
- Build the signed input from the timestamp, one line-feed character, and the raw POST body, in that order.
- Calculate HMAC-SHA256 over that input with the derived key. Compare its hexadecimal representation with
X-Request-Signatureusing a constant-time comparison. - Check that the timestamp is within your configured freshness window before processing the report.
Telegram Gateway expects an HTTP 200 response for callback deliveries and may retry a delivery up to 10 times with increasing delays. Make the handler safe to invoke repeatedly and return the appropriate response for the outcome.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How the five methods differ
| Provider and request type | Verification method | Input or token to verify | Freshness and duplicate handling |
|---|---|---|---|
| Slack requests | HMAC-SHA256 | Versioned string incorporating timestamp and request body; signature in X-Slack-Signature |
Timestamp supports a recency check; handle duplicate events separately |
| GitHub webhooks | HMAC-SHA256 | Exact payload bytes; digest in X-Hub-Signature-256, prefixed sha256= |
No timestamp freshness field in this signature scheme; use an event or delivery identifier for idempotency |
| Microsoft Teams outgoing webhooks | SHA-256 HMAC | Use the exact construction in Microsoft’s current validation instructions; the details must not be inferred from another provider’s method | Freshness behavior depends on the documented construction |
| Google Chat interaction requests | Bearer-token verification | ID token or JWT, according to the configured audience | Use the configured token validation and authorization checks; apply duplicate handling to events where appropriate |
| Telegram Gateway delivery reports | HMAC-SHA256 with a derived key | Timestamp, line feed, and raw POST body; hexadecimal digest in X-Request-Signature |
Check timestamp freshness and make processing idempotent because delivery retries can occur |
Why webhook signature verification fails
- The body was changed before hashing. JSON parsing and reserialization, form parsing, newline conversion, or middleware transformations can alter the bytes. Capture the raw body as the framework receives it.
- The wrong input or secret was used. Check that you selected the correct provider, endpoint configuration, secret, and signed-input construction.
- The header was parsed incorrectly. Preserve required prefixes, capitalization-independent header access, and the provider’s specified digest encoding. Treat header values as untrusted input and reject unexpected formats.
- Timestamp checks disagree. Confirm the provider’s timestamp format, your configured allowed age, and server clock synchronization. Do not silently skip freshness checks when a required timestamp is missing.
- Comparison leaks information. Use a constant-time comparison for secret-dependent signature checks rather than ordinary string equality.
Replay protection and safe event processing
Freshness and idempotency address different risks. A timestamp window can reject an old signed request; it cannot necessarily prevent the same event from being delivered again within that window. Conversely, an event ID can stop duplicate effects but does not prove that a request came from the provider.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Authenticate the request before triggering side effects.
- Where the method provides a timestamp, reject stale requests using a defined age window and synchronized clocks.
- After authentication, record a stable event or delivery identifier and make processing conditional on that identifier not having been completed already.
- Return the provider’s expected success or failure response. Retry behavior differs, so a handler should not assume that every failure will be retried—or that a request will arrive only once.
Keep signing secrets and API tokens server-side, rotate them according to your operational policy, and avoid logging secret values or full authorization tokens. For Teams in particular, rely on Microsoft’s current validation sample for the precise input and header construction rather than adapting code written for another service.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
