How to Test a REST API Online: Free, No Install, 8 Checks

You can test a REST API online without installing anything. Open the free SoftwareTestPilot API Playground in your browser, pick a request such as GET /products/1, press Send, and check three things: the status code, the response body and the headers. Then work through the eight checks below. Together they cover reading data, writing data, login and error handling, the same skills interviewers ask about.

• An online API client. A page where you choose the method (GET, POST, PUT, PATCH, DELETE), enter a URL, add headers and a body, and see the response.
• An API you are allowed to test. A practice API is safest: you can create and delete data freely and break nothing real.
• Basic HTTP knowledge. Methods say what you want to do; status codes say what happened. 2xx means success, 4xx means the request was wrong, 5xx means the server failed (MDN status code reference).

The API Playground gives you the first two together. Each visitor gets a private copy of the practice data, so your changes do not affect anyone else, and you can reset it any time with POST /reset.

All paths below are relative to the practice API base URL https://www.softwaretestpilot.com/api/public/practice/v1. The responses were copied from real requests; ids such as 7 may differ for you.

1. Is the API up?

GET /health

200 OK
{"ok":true,"service":"SoftwareTestPilot QA Practice API","version":"v1"}

Always start here. If health fails, nothing else will pass and you save time.

2. Read one item

GET /products/1

200 OK
{"id":1,"name":"Wireless Test Mouse","category":"electronics","price":899,"stock":42,"active":true}

Check that every expected field is present and has the right type: price is a number, active is true or false.

3. Read a list with paging

GET /products?page=1&limit=5

Expect 200 and a body with data, page, limit and total. Check that data holds at most 5 items and that page 2 does not repeat page 1.

4. Ask for something that does not exist

GET /products/99999

404 Not Found
{"error":{"status":404,"message":"products 99999 not found"}}

A good API returns 404 with a clear message, not 200 with an empty body or a 500.

5. Try to write without logging in

POST /products
Content-Type: application/json

{"name":"Flaky Test Detector","price":499,"category":"tools"}

401 Unauthorized
{"error":{"status":401,"code":"token_missing","message":"Missing Bearer token. POST /auth/login first, then send Authorization: Bearer <token>."}}

This is a security check: protected actions must refuse anonymous callers.

6. Log in and get a token

POST /auth/login
Content-Type: application/json

{"username":"qa.tester","password":"Practice@123"}

Expect 200 with tokenType "Bearer", expiresInSec 900 (15 minutes) and a token. These are public practice credentials, not a real account.

7. Create an item with the token

POST /products
Content-Type: application/json
Authorization: Bearer <token>

{"name":"Flaky Test Detector","price":499,"category":"tools"}

201 Created
{"name":"Flaky Test Detector","price":499,"category":"tools","id":7}

Check the code is 201, not just 200, and that the new id works: GET /products/7 should return the same item.

8. Send invalid data

POST /products
Authorization: Bearer <token>

{"name":"Bad","price":-5,"category":"tools"}

422 Unprocessable Content
{"error":{"status":422,"message":"Validation failed","details":["price must be 0 or more"]}}

Validation tests find many real bugs. Try a missing name, a text price and an empty body next.

Inside the playground everything is wired for you. If you call the API from curl, Postman or code, note one detail: each response includes an X-Sandbox-Key header that identifies your private workspace. Send it back as the X-Sandbox-Key request header on later calls. Without it, each request gets a fresh workspace, and a token from a previous login will be rejected with 401 token_invalid. The full endpoint list, plus Postman and OpenAPI files, is on the API Playground page.

For the full range of API test types beyond these checks (contract, performance, security and more), see types of API testing.

• Only test APIs you own or have permission to test. Practice APIs exist for this reason.
• Never paste real secrets (production keys, personal tokens) into an online tool you do not trust.
• Respect rate limits. The practice API applies a fair-use limit per workspace and tells you with a 429 and Retry-After when you hit it.
• Do not load-test public services. Performance testing needs its own environment and permission.

Using the playground: log in, create a bug with POST /bugs, then try to create one with severity "urgent". What status code do you expect, and why?

Once these eight checks feel natural, automate them so they run on every build. Our Postman API testing tutorial shows how to turn requests into saved tests, and the API testing tutorial covers the concepts in depth. The API Playground also has free ranked challenges if you want structured practice. Stuck on a response you cannot explain? Post it in the QA Community.