API Test Lab is a lightweight API client in your browser. Build GET, POST, PUT, PATCH and DELETE requests with query parameters, headers, a body and authentication, import a cURL command, then inspect the status, headers, timing and formatted response.
Try:
This request has no body. GET and HEAD requests never send one.
Credentials are used only for this request. They are not saved in your history.
Use {{name}} in the URL, headers, body and auth fields. Variables stay in this tab and are not saved.
Requests are sent directly from your browser, so they never pass through our server. The API must allow cross-origin requests (CORS). If it does not, use cURL or a desktop API client for that endpoint.
Because requests come from your own browser, you can also test APIs running on your machine, such as http://localhost:3000.
API Test Lab is a lightweight API client that runs in your browser. Build a request with a method, URL, query parameters, headers, body and authentication, send it, and read the status code, timing, headers and formatted response. Requests go directly from your browser to the API, not through our server.
Paste a cURL command into the URL box and it is turned into a request for you. When you are done, copy the request back out as cURL or JavaScript fetch code.
curl -X POST 'https://jsonplaceholder.typicode.com/posts' \
-H 'Content-Type: application/json' \
-d '{"title":"Hello","userId":1}'
An HTTP request has four parts that matter when debugging: the method, the URL with its query string, the headers and the optional body. The method signals intent. GET and HEAD should be safe and have no side effects, PUT and DELETE are meant to be idempotent, while POST and PATCH usually are not. Sending the same POST twice may create two records, so check before retrying.
Because requests leave your browser directly, the browser enforces CORS. If an API does not return the right Access-Control-Allow-Origin header, the browser may block you from reading the response even though the server received the request. Some headers, such as Host and Cookie, are also controlled by the browser and cannot be set freely. A failure with no status code usually points to CORS, a network error or a mixed-content block rather than a server error.
No. Requests are sent directly from your browser to the API, so your URLs, headers, tokens and bodies never reach our server.
Browsers only allow a page to call another site if that site permits it (CORS). If the API does not send the right CORS headers, or the address cannot be reached, the browser blocks the request. For such APIs, use cURL or a desktop API client.
Yes, for example http://localhost:3000. Your API must allow cross-origin requests from this site, and remote http:// (not https) addresses can be blocked by the browser as mixed content.
No. Authentication values and headers are never stored. History keeps only the method, URL and result, and hides the values of common secret query parameters such as key, token and password.
Browsers do not let pages set certain headers, such as Host, Cookie, User-Agent and Content-Length. They are managed by the browser itself.
Yes, if the service allows CORS. Choose POST, pick the XML body type, paste your envelope and add the SOAPAction header if the service needs it.
No. This tool sends one request at a time. It is for debugging and exploring APIs, not for stress testing.
Browsers apply CORS and mixed-content rules that curl ignores. If the API does not allow your origin, or you call http from an https page, the browser blocks the call before you see a status.
401 means the server could not authenticate you, for example a missing or expired token. 403 means you are identified but not allowed to perform that action on that resource.