Standard Webhooks receiver checker
Updated
Enter the HTTPS address of a webhook receiver. The checker reads the certificate it presents. Then it sends three requests signed under the Standard Webhooks scheme. One is valid, one has its body changed after signing, and one was signed ten minutes ago. You see the status code each one got.
Results for
TLS
Signed requests
| Request | A receiver that verifies | Status | Time | Result |
|---|
What the checker sends
Each request is a POST with a small JSON test event and the three Standard Webhooks headers. webhook-id names the request and webhook-timestamp is unix seconds. webhook-signature is v1, followed by the base64 HMAC-SHA256 of {id}.{timestamp}.{body} under your secret. The event type is webhook.test and each request has its own id, so a receiver that deduplicates on webhook-id still checks all three.
Fax for Agents signs its own deliveries the same way, with the same code. The webhooks documentation has the verification code in Python and TypeScript.
Why send a tampered and a stale copy?
A receiver that only checks for the headers will accept anything. The tampered copy carries a valid signature for a different body, so only a receiver that skips the comparison accepts it. A receiver that checks a re-serialized body instead of the raw bytes refuses the valid copy too. The stale copy is signed correctly but its timestamp is ten minutes old, which catches a receiver that never checks the age of a request. Our own deliveries are refused after 300 seconds. A receiver that verifies answers 2xx to the first copy and something else to the other two.
What do the TLS facts show?
The protocol version, the certificate's subject and issuer, and the chain the server sent. Also the days left before the certificate expires, and whether it names the host you entered. The checker connects with TLS 1.2 or later and checks the chain against a public trust store. Mozilla's intermediate server profile, version 6.0, lists TLS 1.2 and 1.3 and certificate lifetimes of 90 to 366 days. If the certificate does not verify, no request is sent.
What is kept after a run?
The hostname, the address we connected to, the TLS facts, and each request's status code and time, for 30 days, so the permalink works. Not the path or query of your URL, which often holds a token. Not the secret, not the request bodies, and not anything your receiver wrote back. The checker reads at most 16 KB of each answer and throws it away.
Limits
- HTTPS on port 443 to a public hostname. Names that resolve to a private, loopback, link-local or reserved address are refused.
- One endpoint per run, at most four connections, five seconds to connect and five to answer.
- Redirects are recorded as a status code and never followed. No cookies are kept.
- Three runs a minute and twenty an hour from one address, ten an hour against one host.
The results are facts about one run. They are not an audit of your receiver.