Request
Headers
Body
HMAC Signature — optional
Response
Send a request to see the response
Ctrl+Enter / ⌘+Enter
CORS note — Browsers block cross-origin requests unless the target server sends CORS headers. For echo testing, use webhook.site or requestbin.com as the destination — both return full request details with CORS enabled.
Your own API — Works directly if your server sets Access-Control-Allow-Origin: *.
About
The Webhook Tester lets you craft and fire HTTP requests — with full control over the method, headers, and JSON body — and inspect the response without leaving your browser. It is designed for developers who need to test and debug webhook integrations: verify that your endpoint receives the correct payload, confirm response codes, and check response headers before going live. Choose from built-in templates for GitHub Push events, Stripe payment_intent.succeeded, and Slack Events API to instantly load realistic payloads, then customise them to match your exact use case. For services that require signed webhooks, enter your webhook secret and the tool automatically computes an HMAC-SHA256 signature and appends it as a request header — compatible with GitHub, Shopify, and any service using the standard sha256=<hex> convention.
How to use
- 1 Paste your webhook endpoint URL into the URL field and select the HTTP method (POST is the default for most webhooks).
- 2 Optionally choose a template (GitHub, Stripe, Slack) to pre-load a realistic payload, or start with a Custom blank body.
- 3 Edit the JSON body and add or remove request headers as needed.
- 4 To sign the request, enter your webhook secret — the HMAC-SHA256 signature is computed in your browser and added to the header you specify.
- 5 Click Send Request (or press ⌘+Enter) and inspect the response status, headers, and body on the right.
- Why does my request fail with a CORS error?
- Browsers enforce the Same-Origin Policy and block cross-origin requests unless the target server explicitly allows them via CORS headers (Access-Control-Allow-Origin). Most production webhook endpoints are not configured to accept browser requests — they expect server-to-server calls. To work around this during testing, use an echo service like webhook.site or requestbin.com as your target URL; both accept any request with CORS enabled and reflect the full payload back to you.
- How does the HMAC signature work?
- Many webhook providers (GitHub, Shopify, Twilio) require the sender to sign the request body with a shared secret using HMAC-SHA256, then include the signature in a specific header (e.g. X-Hub-Signature-256: sha256=<hex>). The Webhook Tester computes this signature in your browser using the Web Crypto API — your secret never leaves your device — and attaches it to the outgoing request automatically.
- Can I test my local development server?
- Yes — if your local server is running on localhost and has CORS headers enabled (or uses a permissive CORS policy for development), you can enter a localhost URL like http://localhost:3000/webhook. Many frameworks like Express.js, FastAPI, and Laravel can be configured to allow all origins during development.
- What is the difference between a webhook and an API call?
- An API call is initiated by a client polling a server for data. A webhook is a push notification — the server calls your endpoint when an event occurs (payment completed, repo pushed, etc.). Testing a webhook means simulating that server-to-server POST request, which is exactly what this tool does.
- Is my payload or secret sent to any server?
- No. The request is sent directly from your browser to the target URL you specify — it does not pass through any CodeLint.Dev server. The HMAC signature is computed entirely in your browser using the Web Crypto API. Your webhook secret is never transmitted to us.