What an API is

An API is a way for one program to ask another program for something. The name stands for application programming interface, which tells you very little. In practice, and in the rest of this tutorial, an API is a server that answers requests with data instead of web pages.

A weather app on your phone does not store forecasts. When you open it, it sends a request to a server somewhere, gets back a few kilobytes of temperatures and wind speeds, and draws them on the screen. The server part is the API. The app is one of its clients.

Your first request

Paste this address into your browser's address bar and press Enter:

https://api.testingapis.com/api/Products/1

You get back something like this:

{
  "id": 1,
  "title": "Wireless Noise-Cancelling Headphones",
  "price": 249.99,
  "description": "Over-ear headphones with 30hr battery life and active noise cancellation.",
  "category": "electronics",
  "image": "https://picsum.photos/seed/prod1/400/400",
  "rating": { "rate": 4.3, "count": 127 },
  "inStock": true,
  "createdAt": "2025-06-12T10:30:00Z"
}

Your browser sent a request to a server. The server looked up product number 1 and sent back a description of it. That exchange, one request and one response, is what every API interaction comes down to. The rest of this tutorial is about the details of that exchange, and how to check that the server gets them right.

You can also send the request from this page. The Send button below does the same thing your browser just did, and shows the status of the response above the body. You will see these buttons throughout the lessons.

Clients and servers

The program that sends the request is the client. The program that answers is the server. A client can be a browser, a phone app, another server, a command-line tool or a test you wrote. The server can't tell them apart, and it doesn't need to. It reads the request, does its work and replies.

This matters for testing. Because the server treats every client the same way, you can test it without the app that normally talks to it. You don't need to tap through five screens of a shopping app to see whether the product price is right. You ask the API for the product and look at the price.

Endpoints

The address you opened has two parts. https://api.testingapis.com is the base URL: it says which server to talk to. /api/Products/1 is the path: it says what you want from that server. Each path the server understands is called an endpoint. This API has a few hundred. Some examples:

You find out which endpoints exist from the API's documentation. For this API that is the API reference. Real projects vary a lot here. Some have careful docs, some have an OpenAPI file generated from the code, and some have a message in a chat channel from the developer who wrote it. Part of a tester's job is noticing when the docs and the API disagree.

When the answer is no

Now ask for a product that doesn't exist:

The server replies:

{
  "status": 404,
  "error": "Not Found",
  "message": "Product with ID 9999 does not exist."
}

This is also a correct response. There is no product 9999, and the server says so clearly: a 404 status, which means "not found", and a message explaining which ID was missing. A good API is as careful about the requests it can't fulfil as the ones it can. A lot of API testing happens here, on the unhappy path, because that is where developers spend the least time and where most bugs are.

Why test at the API level

You could test everything through the app's screens. Teams test APIs directly for a few practical reasons.

• It is faster. A request takes milliseconds. Clicking through a UI to reach the same state takes seconds, and automating those clicks takes much longer to write and breaks whenever a button moves.
• The API usually exists first. Backend and frontend are often built in parallel, so you can start testing the backend before there is anything to click.
• The UI hides problems. Say a shopping app's quantity box only allows numbers from 1 to 10. The API behind it receives a plain request, and anyone can send one with a quantity of -5. If the server trusts the app to have checked, the order goes through with a negative total. You only find that by talking to the API directly.
• One API often serves several clients: a website, an iPhone app, an Android app, a partner integration. A bug in the API is a bug in all of them.

UI testing still has its place. It is the only way to check that the screens work. But the rules of the system (who can see what, what a valid order looks like, what happens when stock runs out) live in the API, so that is where you check them.