How to test REST API endpoints online

The frontend says the API is broken. The backend says the frontend is calling it wrong. The quickest way to settle it is to send the request yourself and look at exactly what comes back.

REST API basics

REST (Representational State Transfer) is a common style for building web APIs. Each thing the API manages, called a resource, has its own URL, such as /api/users/42. You act on it with standard HTTP methods.

cURL and Postman are the usual tools for sending test requests. An online tester does the same from a browser tab, with nothing to install.

HTTP methods

The method tells the server what you want to do with the resource.

GET, HEAD and DELETE requests normally have no body. POST, PUT and PATCH usually send a JSON body with the data to create or change.

Headers

Headers are the notes clipped to the outside of the envelope: who you are, what’s inside, and what you’d like back. These are the ones you’ll use most:

Content-Type: application/json
Authorization: Bearer <token>
Accept: application/json
X-API-Key: your-api-key

• Content-Type tells the server what format the body is in.
• Authorization sends a token, often a bearer token.
• Accept says which response format you want.
• X-API-Key is a common custom header for API keys.

Request bodies

For POST, PUT and PATCH, the body holds the resource data. JSON is the most common format:

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Priya Raman",
  "email": "priya@example.com",
  "role": "admin",
  "preferences": {
    "theme": "dark",
    "notifications": true
  }
}

Validate the JSON before sending. A missing quote or a trailing comma usually comes back as 400 Bad Request, and the error message rarely says which comma. The JSON formatter will point to the exact line.

How to use the API tester

1. Open the API response tester and pick a method: GET, POST, PUT, PATCH, DELETE or HEAD.
2. Enter the full URL of the endpoint.
3. Add request headers as a JSON object, for example {"Content-Type": "application/json", "Authorization": "Bearer <token>"}. The tester checks that the headers are valid JSON before sending.
4. For POST, PUT, PATCH and DELETE, enter the request body. It is sent exactly as typed. The tester does not add a Content-Type for you, so include "Content-Type": "application/json" in the headers when you send JSON.
5. Select Send or press Enter in the URL field.

The response panel shows the status code and text, the time the request took in milliseconds, the response headers and the body. JSON bodies are pretty-printed, and you can Copy the body.

Requests are sent from PulpMiner’s server, not from your browser. That has three effects:

• Browser CORS rules (explained below) don’t apply, so APIs that block requests from web pages still work.
• Only public URLs can be reached. localhost and private network addresses are blocked, so use cURL to test a server running on your own machine.
• Your headers pass through PulpMiner on their way to the API, so use test keys rather than production secrets.

Reading the response

The status code says whether the request worked: 200 or 201 for success, 400, 401 or 404 for problems with the request, 500 and up for server errors. Headers can carry rate limits, pagination links and caching rules. The body holds the data.

HTTP/1.1 200 OK
Content-Type: application/json
X-RateLimit-Remaining: 98

{
  "id": 42,
  "name": "Priya Raman",
  "email": "priya@example.com",
  "createdAt": "2026-02-07T10:30:00Z"
}

For a full list of codes, see the HTTP status codes reference.

CORS and browser-based testing

If you call an API with fetch from your own web page, you may hit CORS (Cross-Origin Resource Sharing) errors. Browsers block a page from reading a response from another origin, meaning a different domain, port or protocol, unless the server allows it with an Access-Control-Allow-Origin header.

This is a browser rule, not an API failure, and it has started many arguments between frontend and backend teams. The same request works from cURL, Postman, a backend server or the API tester. That makes the tester a quick way to check whether a failure is CORS or a real API problem. To fix it for your app, ask the API owner to allow your origin, or call the API from your backend.

What to test

• Authentication: send the request with a valid token, an invalid one and none, and check for 401 or 403 where expected.
• Validation: send missing or malformed fields and check that the error messages are useful.
• Pagination: request different pages and page sizes and check the links or cursors in the response.
• Errors: request a resource that does not exist and expect a 404.

The API tester is for quick, exploratory checks. For automated tests and CI pipelines, use a test framework such as Jest or Vitest with Supertest, or Playwright’s API testing.

When you do need a terminal, the same request in cURL looks like this, with your token in the TOKEN environment variable:

curl -X POST https://api.example.com/api/users \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"name": "Priya Raman", "email": "priya@example.com"}'