Build a request — method, URL, headers, a bearer token or basic auth, a JSON body — and send it. The response comes back with its status, timing, headers and a formatted body, and the same request is ready as a curl command.
Requests go straight from your browser to the API you enter. Upzilla never sees the URL, the token or the response.
A REST API is a set of URLs that answer to HTTP methods. GET reads a resource, POST creates one, PUT replaces it, PATCH changes part of it and DELETE removes it. To test an endpoint you send a request with the right method, headers and body and look at three things in the answer: the status code, the headers and the body.
This tester sends the request with the browser's own fetch, so it behaves exactly like the front-end code of a web app would. That makes it a quick way to answer "does my API answer this page correctly?" — including its CORS headers.
2xx means the request worked, 3xx a redirect, 4xx a problem with the request (auth, validation, missing resource) and 5xx a failure on the server.
Content-Type says how to read the body, Cache-Control how long it may be kept, and rate-limit headers how many calls you have left.
Usually JSON. A 4xx or 5xx answer often carries an error object that explains what went wrong — read it before guessing.
The full round trip from this browser: DNS, connection, TLS, server work and download. A slow first call and fast later ones point to connection setup or a cold cache.
Browsers enforce the same-origin policy. A page may call an API on another domain only when that API answers with an Access-Control-Allow-Origin header that permits it. For anything but a simple GET, the browser first sends an OPTIONS "preflight" request and checks the answer before sending yours. Public APIs built for front-ends allow this; internal APIs and many server-to-server APIs do not.
When the browser blocks a response, the page cannot see why — the request may well have reached the server and succeeded. That is why every request is also shown as a curl command: curl has no same-origin policy, so it shows the API's real answer. Browsers also refuse to set some headers themselves, such as Host, Cookie and User-Agent; use curl when you need to control those.
http://localhost can be called from this page if it sends CORS headers — but only when the page itself is not on https, because browsers block https pages from calling plain http.The API did not include an Access-Control-Allow-Origin header that allows this page, so the browser hides the response. The API itself may be fine. Run the curl command shown below the form to see its real answer, or allow the origin in the API's CORS settings.
No. The request goes directly from your browser to the URL you enter. Nothing — URL, headers, token or response — passes through Upzilla's servers.
Choose POST, PUT or PATCH, paste the JSON into the Body field and keep "Send body as JSON" ticked. The tester checks the JSON is valid and adds Content-Type: application/json unless you set your own.
PUT replaces the whole resource with the body you send; fields you leave out are usually cleared. PATCH changes only the fields in the body. Which one an API supports, and how strictly, is up to the API.
Yes, if the local server sends CORS headers. Browsers block an https page from calling plain http, so for http://localhost use the curl command, or serve your API over https.
Upzilla checks your sites, servers and APIs around the clock and alerts you the moment something breaks. 10 monitors free, no card required.