Build HTTP requests, fire them, and inspect responses. A lightweight REST client in your browser.
Note: Requests are sent directly from your browser, so CORS restrictions apply. The target server must allow cross-origin requests.
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.
The scenarios where a browser-based sender is the right tool:
/webhooks/stripe route in your app. Fire a sample payload at it and check the response, the logs, and any downstream side effects.Stripe-Signature header to confirm your verification middleware accepts valid signatures and rejects invalid ones.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:
https://www.forgelit.com (or * during dev) to your CORS config. Most frameworks let you do this with one line of middleware.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.
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.
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.
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.
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.
Yes. No signup, no limits, no ads. The tool runs entirely in your browser, so there is nothing to pay for.
No. This is a webhook sender and REST client, not a public catch-all URL. If you need a URL that receives incoming webhooks from third-party services so you can inspect the payloads they send, you want a service like webhook.site, RequestBin, or Hookdeck. This tool is for the other half of the problem: firing test requests at your own endpoints to see how they behave.
Because the request is made from your browser, the target server has to explicitly allow cross-origin requests via the Access-Control-Allow-Origin header. If you are testing your own endpoint, add https://www.forgelit.com to the allowed origins in your CORS config during development. If you are testing a third-party API that does not allow browser requests, you will need a server-side tool like curl, Postman's desktop app, or an HTTP client library instead.
Yes, via the Headers section. Add an Authorization header with the value Bearer YOUR_TOKEN for Bearer auth, Basic base64-encoded-credentials for Basic auth, or any custom header name for API keys (X-API-Key, X-Auth-Token, and so on). The headers you add are sent exactly as typed.
Postman and Insomnia are much more full-featured: collections, environments, scripting, team sharing, mock servers, test assertions. This tool is deliberately lighter weight. It opens instantly in a browser tab, has zero setup, and does not require an account. Think of it as the tool you reach for when you need to fire one request right now, not when you are managing a whole API workspace.
No. Requests go directly from your browser to the target URL you enter. Nothing is proxied through Forgelit, and no payload data is sent to any Forgelit server. We cannot see what you send or receive.
Requests go directly from your browser to the target URL. Nothing is proxied or logged by Forgelit.