How to Test a REST API Endpoint: Methods, Headers, Status Codes, and CORS

Before you write integration code against an API, send it a few requests by hand. Five minutes of manual testing tells you what the response really looks like, whether your credentials work, and which errors you’ll need to handle. That’s much cheaper than discovering it through a failing build.

This is a repeatable routine for testing a REST endpoint, using the free API Tester in the browser. The steps are the same in any client. If you’re choosing between tools rather than learning the routine, see Postman alternatives for quick API tests.

Step 1: Start with a plain GET request

Pick the simplest read-only endpoint in the docs and request it with no headers. JSONPlaceholder is a free fake API that’s handy for practice:

GET https://jsonplaceholder.typicode.com/posts/1

A working request returns status 200 and a JSON body. This first call confirms the base URL, that the server is reachable, and what the data shape looks like. If even this fails, there’s no point adding authentication yet.

Step 2: Add the headers the API expects

Most real APIs need a few headers:

A wrong or missing token usually returns 401 Unauthorized. A valid token without the right permission returns 403 Forbidden. Seeing which one you get tells you whether the problem is the token itself or its scope.

In the API Tester, headers are added as name/value pairs and are never saved or put into shareable links, because they so often contain secrets.

Step 3: Send a body with POST, PUT, or PATCH

Write operations send data in the request body. Match the body to the Content-Type header:

POST https://jsonplaceholder.typicode.com/posts
Content-Type: application/json

{
  "title": "Hello",
  "body": "From the API Tester",
  "userId": 1
}

JSONPlaceholder answers with 201 Created and echoes the resource back with a new id (it’s always 101, since nothing is really stored). Real APIs typically return the created resource or its URL in a Location header.

The difference between the write methods matters: PUT replaces the whole resource, PATCH changes only the fields you send, and DELETE removes it (often answering 204 No Content, with an empty body).

Step 4: Read the status code first

The status code tells you what happened before you read a single byte of the body:

Step 5: Look at the response headers

Headers carry information the body doesn’t. Three worth checking on every new API:

• Content-Type confirms you actually got JSON and not an HTML error page.
• Cache-Control tells you how long the response may be cached. The GitHub API, for example, sends public, max-age=60 on public user data.
• Rate-limit headers show your budget. The same GitHub endpoint returns x-ratelimit-limit: 60 and x-ratelimit-remaining for unauthenticated requests, so you can see exactly how many calls you have left this hour.

Try the GitHub User sample in the API Tester and open the Headers tab to see them.

Step 6: If the request fails in the browser, check CORS

Browsers enforce CORS (Cross-Origin Resource Sharing): a page on one site may only read responses from another site if that server explicitly allows it with an Access-Control-Allow-Origin header. APIs designed for browser use, like GitHub’s public API and JSONPlaceholder, send Access-Control-Allow-Origin: *. Many private or server-to-server APIs don’t.

Two details explain most CORS confusion:

• Preflight requests. Adding an Authorization header or sending Content-Type: application/json makes the browser send an OPTIONS “preflight” request first. If the server doesn’t answer it with the right Access-Control-Allow-* headers, the real request is never sent.
• Opaque errors. When CORS blocks a response, JavaScript only sees a generic network error (“Failed to fetch” in Chrome, “NetworkError” in Firefox, “Load failed” in Safari). The detailed “blocked by CORS policy” message appears only in the browser console.

When the API Tester hits one of these failures, it explains the likely causes and lets you Copy as cURL. CORS is a browser rule, so the same request from a terminal or from your own backend works if the endpoint itself is fine. If you control the API, add the allowed origin. If you don’t, call it from your server instead of the browser.

A related trap: a page served over https:// can’t call a plain http:// API. The browser blocks it as mixed content. Use the API’s HTTPS URL.

Step 7: Move the request into code

Once a request works, don’t retype it. The API Tester’s Copy as fetch() produces the JavaScript equivalent with your method, headers, and body:

const response = await fetch("https://jsonplaceholder.typicode.com/posts", {
  "method": "POST",
  "headers": { "Content-Type": "application/json" },
  "body": "{\"title\":\"Hello\",\"body\":\"From the API Tester\",\"userId\":1}"
});
const data = await response.text();

Add error handling for the status codes you saw in testing (401, 404, 422, 429) before it ships.

Testing checklist

1. A plain GET works and returns the shape you expect.
2. Authentication: a correct token returns 200, a wrong one 401, and a token without permission 403.
3. Write methods return 201 or 204, and invalid input returns 400 or 422 with useful details.
4. Headers checked: Content-Type, caching, rate limits.
5. If it’s called from a browser, CORS allows your origin.
6. Copy the working request into code and handle the error codes you found.

Open the API Tester and try the samples: a GET, a POST with a JSON body, and the GitHub API with its rate-limit headers.