Webhook Tester

What this webhook tester is (and what it is not)

This is a sender. You give it a URL, an HTTP method, headers, and a body, and it fires the request straight from your browser and shows you the response. It is a lightweight REST client you can open in a tab without installing anything.

It is not a receiver. If you are looking for a public URL that catches incoming webhooks from Stripe, GitHub, Shopify, or any other service so you can inspect what they send, this is the wrong tool. For that job, use webhook.site, RequestBin, or Hookdeck. Those services give you a temporary URL, collect requests sent to it, and let you replay them. This tool solves the other half of the webhook problem: testing how your own endpoint behaves when a payload arrives.

What it is good for

The scenarios where a browser-based sender is the right tool:

• Testing a webhook handler you just deployed. You wrote a /webhooks/stripe route in your app. Fire a sample payload at it and check the response, the logs, and any downstream side effects.
• Debugging an integration that is not receiving the expected payload. Replay a request with the exact shape you think the provider is sending, and see if your endpoint matches that assumption.
• Validating signature verification logic. Send a request with a known HMAC or Stripe-Signature header to confirm your verification middleware accepts valid signatures and rejects invalid ones.
• Poking at any REST API. It is also a general HTTP client. If you need to hit a GET endpoint to see what it returns, or POST to a JSON API while prototyping, this works the same way Postman or curl would.
• Sharing a repro case. The request you built can be copied as a curl command and dropped into an issue or a chat message.

The CORS constraint (and how to work around it)

Because requests fire from your browser, the target server has to opt in to cross-origin requests via the Access-Control-Allow-Origin header. This is a browser security rule, not something the tool can bypass.

In practice, this affects you in one of three ways:

• Testing your own endpoint in development: add https://www.forgelit.com (or * during dev) to your CORS config. Most frameworks let you do this with one line of middleware.
• Testing a public API that supports browser clients: services like httpbin, JSONPlaceholder, and most modern REST APIs already allow cross-origin requests. You can use this tool as-is.
• Testing a third-party API that blocks browser requests: you cannot work around this with a browser tool, period. Use curl, Postman's desktop app, or an HTTP client library in a terminal instead. The CORS block is the server's decision, not ours.

If you hit a CORS error, the response area will show an empty or errored response and the browser console will explain why. The tool itself is working. The target is refusing the cross-origin connection.

Webhook anatomy, briefly

If you are newer to webhooks, the request model is the same as any HTTP API call. A webhook is just an HTTP POST (usually) sent to a URL you control, by a service reacting to an event on their end.

The four parts of any request

URL: where the request is sent. For webhook testing, this is usually your own /webhooks/provider route. Method: almost always POST for webhooks, but you can test any HTTP verb here. Headers: metadata like Content-Type: application/json, authentication, and signature values. Body: the payload, almost always JSON.

Signature headers you will encounter

Most providers sign their webhooks so your endpoint can verify the request really came from them. The header names vary: Stripe uses Stripe-Signature, GitHub uses X-Hub-Signature-256, Shopify uses X-Shopify-Hmac-SHA256, and many custom integrations use a generic X-Signature or X-Hmac. When testing locally, you can construct a valid signature using the provider's documented algorithm and paste it into the Headers section here.

Response codes your endpoint should return

By convention, webhook receivers return 200 OK or 204 No Content when the payload was accepted successfully. Any 2xx means "I got it, do not retry". Most providers treat 4xx as permanent failures (bad payload, auth failed) and 5xx as temporary failures worth retrying. If your endpoint is returning 500 on valid payloads, the provider will eventually give up. If it returns 200 on broken payloads, you will silently lose events.