阅读结果下方显示的逐步解题过程,了解所用方法。
Webhook/HTTP请求测试工具
关于此工具
从浏览器构建并发送HTTP请求,详细检查响应。
使用方法
- 1 JSON响应以语法高亮格式化显示;其他所有响应以纯文本显示。
- 2 选择HTTP方法(GET、POST、PUT、PATCH、DELETE)并输入目标URL。
- 3 使用键值编辑器添加所需的请求头;使用预设快捷方式添加常用请求头。
- 4 对于POST/PUT/PATCH请求,输入请求体并选择Content-Type。
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
Authorizationheader 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, andUser-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.