REST API Tester
Send a real HTTP request to any public API and see what comes back: status code, response time, headers and the formatted body. No installation and no CORS problems, since the request is sent from our server on your behalf.
- Encrypted connection
- No sign-up
- Free to use
The request is sent from our server, not from your browser, so it works without CORS. It can only reach public addresses on ports 80 and 443; localhost and private networks are blocked. Credentials you enter pass through our server to the API and are not stored or logged.
Response
| Header | Value |
|---|
How to use REST API Tester
- Choose the method and enter the URL of a public API endpoint.
- Add query parameters, headers and authentication as the API requires.
- For POST, PUT and PATCH, choose a body type and enter the data.
- Select Send request and read the status, body, headers and timing.
REST API Tester features
All common methods
GET, POST, PUT, PATCH, DELETE, HEAD and OPTIONS.
Authentication
Bearer tokens, Basic authentication and API keys in a header or in the URL.
JSON, forms, XML, text
Bodies are sent with the matching Content-Type; multipart forms with text fields are supported.
Full response
Status, HTTP version, every response header, the body formatted when it is JSON, and its size.
Timing breakdown
DNS lookup, connection, TLS handshake, time to first byte and total time.
cURL equivalent
Each request is also shown as a cURL command you can run locally.
When to use REST API Tester
- Trying an endpoint from API documentation before writing code.
- Checking whether an API is up and how fast it answers from outside your network.
- Reproducing a failing request with exact headers and body.
- Inspecting the headers of a webhook receiver or a public endpoint.
REST API Tester FAQ
Where is the request sent from?
From our server. A browser page may not read responses from other origins unless the API explicitly allows it (CORS), which would make most APIs untestable from a web page. Relaying the request avoids that. The API therefore sees our server's IP address, not yours.
Can I test an API on localhost or in my private network?
No. Our server cannot reach your machine, and requests to private, loopback and reserved addresses are blocked on purpose, so that the tool cannot be used to probe internal networks. For local APIs, copy the cURL command shown under “Request sent” and run it on your computer.
Is it safe to enter my API key?
The request, including credentials, travels over HTTPS to our server and from there to the API. It is not stored or written to logs, and credential headers are masked in the request summary. Even so, the careful choice is a test key or a short-lived token with limited permissions, and never a production secret you cannot rotate.
What are the limits?
Request bodies up to 100 KB, responses up to 1 MB, a 20-second timeout, up to five redirects, ports 80 and 443 only, and a limit on requests per visitor. File uploads are not available.
Why are some of my headers not sent?
Headers that describe the connection itself, such as Host, Content-Length, Connection and Transfer-Encoding, are set by the HTTP client and cannot be overridden. They are listed as “not sent” in the request summary.
Does it follow redirects?
Only if you tick the box. By default you see the 3xx response and its Location header, which is usually what you want when debugging. When following, credentials are not passed on to a different host.
Testing an API by hand
Before any code is written against an API, it pays to make a few requests by hand. You learn what the endpoint really returns, how errors look, which headers are required and how long a call takes. Documentation describes intent; a response shows fact. An API tester is the quickest way to get that response: it lets you set every part of a request explicitly and shows every part of the answer.
Reading a response starts with the status code. 2xx means the request was accepted. 4xx means it was not, for a reason on your side: 400 for malformed input, 401 for missing or wrong credentials, 403 for insufficient rights, 404 for a wrong URL, 422 for data that fails validation, 429 for too many requests. 5xx means the server failed. The body of an error response normally explains the problem, and the headers add context such as rate-limit counters and request IDs.
Good tests are small and deliberate. Change one thing at a time. Send the request without credentials to confirm that authentication is enforced, with a wrong field to see the validation message, and with the exact example from the documentation to establish a baseline. Remember that write methods have real effects on a live system: use a sandbox or test account for POST, PUT and DELETE whenever the provider offers one.
A web-based tester has specific properties. Requests originate from a server on the public internet, which is useful for checking how an endpoint behaves from outside, and which rules out private addresses. For day-to-day work against local or internal services, a command-line client such as cURL or a desktop API client is the right companion; the cURL command generated for each request makes it easy to move between the two.