Testador de Webhook / Requisição HTTP

What this tool actually does

This is an HTTP request builder that sends a real network request from your browser and shows you the full response. You pick a method (GET, POST, PUT, PATCH, DELETE), type a URL, optionally add headers and a request body, and press Send. Under the hood it calls the browser's standard fetch() API, so the request leaves your machine and travels to the server you named — this is not a simulation, and the URL and any data you send go to that endpoint. The response status, headers, body, and round-trip time come back and are displayed, with JSON automatically pretty-printed.

The CORS reality you must understand

Because the request originates from a web page, it is governed by the browser's same-origin policy and CORS (Cross-Origin Resource Sharing) rules. When you call an API on a different domain than this site, the browser only hands you the response if that server explicitly opts in by returning an Access-Control-Allow-Origin header that permits the request. If the server does not, the browser blocks the response and you get a network/CORS error — even though the server may have received and processed the request. The tool detects this case and shows a hint that it is "likely a CORS error."

This is a browser limitation, not a bug. It means this tester works perfectly against:

• APIs that are CORS-enabled (many public REST and testing APIs are);
• your own server, once you add the right CORS headers;
• any endpoint behind a proxy you control that adds CORS headers.

For testing arbitrary third-party APIs that lack CORS, a desktop client like curl or a server-side script is the right tool, because those are not bound by browser CORS.

A worked example

Select POST, enter a URL such as a CORS-friendly echo endpoint, click + Content-Type (which inserts the header Content-Type: application/json), choose the JSON body type, and paste:

{"name": "Ada", "role": "engineer"}

Press Send. The tool builds the request, sends the body, and renders the response: a coloured status badge (green for 2xx, orange for 4xx, red for 5xx), the elapsed milliseconds, a table of every response header, and the body. If the server echoes JSON back, it is reformatted with two-space indentation against a dark background so it is easy to read. The exact request — method, URL, headers, and body — is saved to a local history of your last five requests, which you can click to reload and resend.

Headers and body types

The Headers section lets you add any key/value pair, with one-tap presets for the three most common: Content-Type, Authorization (pre-filled as Bearer so you just paste your token), and Accept. The body editor appears only for methods that carry a payload (POST, PUT, PATCH) and offers three encodings:

• JSON → sends application/json;
• Form URL-encoded → sends application/x-www-form-urlencoded (e.g. key=value&other=data);
• Plain Text → sends text/plain.

If you have not already set a Content-Type header yourself, the tool adds the matching one automatically based on the body type you chose. A header you set manually always wins.

Common use cases

• Inspecting a webhook payload format. Fire a sample POST at your receiver and confirm it accepts the body shape you intend to send.
• Checking an API quickly without opening a terminal — verify a GET returns the data you expect, or that an auth token is accepted.
• Reading response headers such as rate-limit counters, cache directives, or content type, all laid out in a table.
• Reproducing a request from history to compare two runs after a change.

Tips and common mistakes

• A blank response is usually CORS, not a dead server. If you get an immediate failure on a third-party URL, the server almost certainly received the request but the browser withheld the response. Test against your own CORS-enabled endpoint to confirm your request is correct.
• Real credentials are really sent. Anything you put in an Authorization header or body goes to the destination server over the network. Only paste tokens for endpoints you trust, and avoid production secrets in casual testing.
• Some headers cannot be set from a browser. The fetch API forbids "unsafe" headers like Host, Origin, and User-Agent; the browser controls those. If a server needs them, use a server-side client.
• History is local only. Your last five requests are stored in this browser's localStorage, not on any server, and you can clear them at any time. They never sync to another device.