APITesterHow the webhook URL works. It is a public address that records whatever is sent to it and
answers 200. An inbox keeps the 50 most recent requests, accepts bodies up to 256 KB, and is
deleted 24 hours after it was created — or sooner if you press Delete URL or our server
restarts, because requests are held in memory and never written to disk.
Anyone who has the URL can read what it received. Use sandbox and test-mode accounts, do not route production traffic or customer data through it, and delete it when you are done. Privacy details.
What is a webhook?
A webhook is an HTTP request that one service sends to a URL you give it when something happens: a payment
succeeds, a commit is pushed, a message arrives. Instead of your code asking an API again and again whether
anything has changed, the provider calls you. In practice that is a POST with a JSON or
form-encoded body, a few provider-specific headers, and usually a signature you are expected to check before
trusting any of it. Your endpoint answers quickly with a 2xx and does the real work afterwards.
The guide to what a webhook is goes through each of those steps,
with the signature check and the retry rules in full.
Examples by provider
Stripe Webhook Example
What Stripe actually sends to your endpoint — the event envelope, the Stripe-Signature header and the retry behaviour — with a webhook URL you can create here to catch a real one.
GitHub Webhook Example
The headers and JSON GitHub posts when a repository event fires, how X-Hub-Signature-256 is computed, and what happens when your endpoint is down.
PayPal Webhook Example
The notification PayPal posts when a payment event happens — its envelope, the five PAYPAL- headers, and the certificate-based signature that works differently from everyone else's HMAC.
Shopify Webhook Example
What Shopify posts when a store event fires — the topic and shop headers, the resource JSON, and a base64 HMAC that trips up people expecting hex.
Zapier Webhook Example
Zapier works in both directions.
Slack Webhook Example
The JSON Slack's Events API posts to your Request URL, the one-time url_verification handshake, and the v0 signature that covers a timestamp as well as the body.
Discord Webhook Example
A Discord webhook runs the other way from most: you send the request, and Discord posts it in a channel.
Twilio Webhook Example
Twilio's webhooks are form posts, not JSON, and the signature covers your URL as well as the parameters.
GitLab Webhook Example
The JSON a GitLab project webhook posts on a push, the headers that describe it, and the secret token that is compared rather than computed.
Telegram Webhook Example
The Update object Telegram posts to a bot's webhook, the optional secret-token header, and the trick of answering with an API call in the response body.
SendGrid Webhook Example
SendGrid's Event Webhook posts a batch — a JSON array of email events — and signs it with ECDSA rather than an HMAC.
WooCommerce Webhook Example
What a WooCommerce store posts when an order, product or customer changes — the X-WC-Webhook-* headers, the REST-shaped JSON, and the rule that switches a failing webhook off.
Mailchimp Webhook Example
Mailchimp audience webhooks are form posts with bracketed field names, and they carry no signature at all.
HubSpot Webhook Example
HubSpot delivers CRM events in batches: one request, a JSON array, each element a small notification that names a record without containing it.
Square Webhook Example
Square signs the notification URL together with the body, so a request that is perfectly genuine fails verification when your server disagrees about its own address.
Bitbucket Webhook Example
Bitbucket Cloud webhooks look like GitHub's at first glance and differ in the details that break copied code: the event name header, the signature header's name, and the shape of a push.
Jira Webhook Example
A Jira webhook delivers the whole issue plus a changelog of exactly what was edited.
Mailgun Webhook Example
Mailgun puts its signature inside the JSON body instead of in a header, and that signature covers a timestamp and a token rather than the event itself.
Typeform Webhook Example
A Typeform webhook sends one form submission: the questions as they were defined and the answers as they were given, in two separate arrays you have to join yourself.
Calendly Webhook Example
Calendly webhooks are created through the API rather than a settings page, and they describe everything by URI.
Linear Webhook Example
A Linear webhook reports a change to one entity — an issue, a comment, a project — and, on updates, tells you the previous values of whatever changed.
Clerk Webhook Example
Clerk delivers its webhooks through Svix, so the three svix- headers and their signing scheme are shared with every other service that uses the same infrastructure.
Paddle Webhook Example
Paddle Billing notifications look a lot like Stripe's until you parse the signature header, which uses different separators and joins the timestamp to the body differently.
Razorpay Webhook Example
Razorpay wraps each event's entities inside payload under their own names, and signs the body with a secret you choose when creating the webhook.
Twitch Webhook Example
Twitch EventSub sends three kinds of message to the same URL, told apart by a header: a challenge to prove you own the endpoint, the notifications themselves, and a revocation when a subscription ends.
Zoom Webhook Example
Zoom will not save a webhook endpoint until it has answered a validation challenge with a hash made from the app's Secret Token, and it repeats that check from time to time.
WhatsApp Webhook Example
WhatsApp Cloud API webhooks come from Meta's shared webhook system: a GET challenge when you register the URL, then deeply nested JSON for every incoming message and every delivery status.
Dropbox Webhook Example
A Dropbox webhook tells you who has changes and nothing about what changed.
Asana Webhook Example
Asana hands you the signing secret instead of asking for one: it arrives once, in a header, during a handshake your endpoint has to answer.
Okta Webhook Example
An Okta event hook delivers System Log events to your endpoint, authenticated by a header and secret you choose rather than by a signature.
How the providers differ
"Verify the signature" is one sentence that means a different procedure for almost every sender. The table below is the short version; each provider's page has the header list, a verification function and the details.
| Provider | Body | How the request is authenticated | Header | Retries a failed delivery? |
|---|---|---|---|---|
| Stripe | JSON | HMAC-SHA256, hex, over timestamp + body | Stripe-Signature | Yes — backoff over days |
| GitHub | JSON or form | HMAC-SHA256, hex, over body | X-Hub-Signature-256 | No — redeliver manually |
| PayPal | JSON | RSA signature, verified by certificate or API | PAYPAL-TRANSMISSION-SIG | Yes — over days |
| Shopify | JSON | HMAC-SHA256, base64, over body | X-Shopify-Hmac-Sha256 | Yes — over hours |
| Zapier | Form by default, or JSON | None — add your own secret header | — | Not automatically |
| Slack | JSON | HMAC-SHA256, hex, over timestamp + body | X-Slack-Signature | Yes — a few attempts |
| Discord | JSON (you send it) | None — the URL is the secret | — | You handle 429s |
| Twilio | Form-encoded | HMAC-SHA1, base64, over URL + params | X-Twilio-Signature | Fallback URL instead |
| GitLab | JSON | Plain secret token, compared | X-Gitlab-Token | Disables failing hooks |
| Telegram | JSON | Plain secret token, compared | X-Telegram-Bot-Api-Secret-Token | Yes — limited attempts |
| SendGrid | JSON array (batched) | ECDSA, base64, over timestamp + body | X-Twilio-Email-Event-Webhook-Signature | Yes — about a day |
| WooCommerce | JSON | HMAC-SHA256, base64, over body | X-WC-Webhook-Signature | No — disables after 5 failures |
| Mailchimp | Form-encoded | None — put a secret in the URL | — | Yes — for about an hour |
| HubSpot | JSON array (batched) | HMAC-SHA256, base64, over method + URL + body + timestamp | X-HubSpot-Signature-v3 | Yes — over about a day |
| Square | JSON | HMAC-SHA256, base64, over URL + body | x-square-hmacsha256-signature | Yes — over about a day |
| Bitbucket | JSON | HMAC-SHA256, hex, over body | X-Hub-Signature | Yes — a few attempts |
| Jira | JSON | HMAC-SHA256, hex, over body, if a secret is set | X-Hub-Signature | Yes — a few attempts |
| Mailgun | JSON | HMAC-SHA256, hex, over timestamp + token, carried in the body | — | Yes — over hours, unless you answer 406 |
| Typeform | JSON | HMAC-SHA256, base64, over body | Typeform-Signature | Some failures; 404 or 410 disables it |
| Calendly | JSON | HMAC-SHA256, hex, over timestamp + body | Calendly-Webhook-Signature | Yes — over about a day |
| Linear | JSON | HMAC-SHA256, hex, over body | Linear-Signature | Yes — a few attempts |
| Clerk | JSON | HMAC-SHA256, base64, over id + timestamp + body | svix-signature | Yes — over about a day |
| Paddle | JSON | HMAC-SHA256, hex, over timestamp + body | Paddle-Signature | Yes — over days |
| Razorpay | JSON | HMAC-SHA256, hex, over body | X-Razorpay-Signature | Yes — over about a day |
| Twitch | JSON | HMAC-SHA256, hex, over message id + timestamp + body | Twitch-Eventsub-Message-Signature | Yes — then revokes the subscription |
| Zoom | JSON | HMAC-SHA256, hex, over timestamp + body | x-zm-signature | Yes — a few attempts |
| JSON | HMAC-SHA256, hex, over body | X-Hub-Signature-256 | Yes — over days | |
| Dropbox | JSON (account ids only) | HMAC-SHA256, hex, over body | X-Dropbox-Signature | Yes — then disables the URI |
| Asana | JSON (compact events) | HMAC-SHA256, hex, over body, with a secret Asana issues in the handshake | X-Hook-Signature | Yes — then deletes the webhook |
| Okta | JSON (batched events) | Plain secret in a header you name, compared | Authorization | At most once |
Three patterns cover most of it. A body HMAC (GitHub, Shopify, WooCommerce) proves who sent the request and that it was not altered, but not when it was sent. A timestamped HMAC (Stripe, Slack) adds freshness, so a captured request cannot be replayed later. A plain token (GitLab, Telegram) only proves the sender knows the secret, which makes HTTPS mandatory. The webhook tester guide goes through verification, retries and idempotent handlers in depth.
Using a webhook URL to debug an integration
- Create a webhook URL above and copy it.
- Register it as the endpoint in the provider's sandbox or test mode.
- Trigger an event — a test payment, a push, a message.
- Read the request: which headers arrived, what the content type is, how the body is shaped.
- Replay it against your own server with Open in API Tester or Copy as cURL.
That replaces the usual first hour of an integration — deploying a handler just to log what the provider sends. It does not replace a tunnel when you need to step through your own code on a real delivery with a live signature; a replayed request is only as fresh as its timestamp.
Specifications and references
- RFC 2104: HMAC — The keyed-hash construction behind most webhook signatures.
- Standard Webhooks — An open specification for webhook headers, signatures and retries that several providers follow.
- CloudEvents — A CNCF specification for describing event data in a common way.
- Node.js: crypto.timingSafeEqual() — The constant-time comparison the verification functions on these pages use.
These links leave api-tester.com, which is independent of the companies and projects they point to.
Webhook examples FAQ
What is a webhook example?
A captured or representative HTTP request from a provider: the method, the headers it sets, and the body it sends. Reading one tells you what your endpoint has to parse and verify before you write any code.
Are these real payloads?
They follow each provider's documented format, but every id, token and signature is a placeholder. A sample signature will not verify. To see a genuine delivery, create a webhook URL and register it with the provider's sandbox.
How do I get a URL to receive webhooks?
Press Create webhook URL on any page in this section. You get a public HTTPS address that records the requests sent to it for 24 hours, with no account.
Why do signature checks fail on a payload that looks correct?
Because the signature covers the exact bytes that were sent. Parsing the JSON and serialising it again changes whitespace or key order, so verify against the raw request body.
Do all providers sign webhooks the same way?
No. Most use an HMAC-SHA256 of the body with a shared secret, but the encoding differs between hex and base64, some include a timestamp, Twilio signs the URL and parameters with HMAC-SHA1, PayPal and SendGrid use public-key signatures, and GitLab and Telegram send a plain secret token.