When you click "Log in," the page doesn't decide on its own whether the password is correct — it sends a request to a server and gets a response back. This way of a program talking to a server is called an API. You can test not just buttons, but the exchange itself — directly, without any UI. The tool for this is Postman.

It sounds technical, but at the basic level it's simple: a request is a "question" to the server, a response is its "reply." Let's look at what these questions and replies are, and how to send them by hand.

What an API is in plain words

An API is the way one program talks to another. For a tester, the most common variety is the exchange over HTTP — the same protocol that websites use.

An analogy: an API is a waiter. You (the page) tell the waiter (the API) "bring me my list of orders," the waiter goes to the kitchen (the server) and comes back with the dish (data). You don't need to know how the kitchen works — you just need to place the order correctly and check what was brought.

Why test an API separately from the UI:

  • Faster. Checking a dozen request variations directly is much quicker than clicking through screens.
  • Deeper. Sometimes the bug is in the API and the UI hides it (or vice versa). Testing directly, you know exactly where things are broken.
  • Earlier. An API is often ready before the UI is — you can start testing before there are any buttons.

What a request is made of

Every request has several parts:

  • Method — what we want to do. The main ones: GET (retrieve data — "show my orders"), POST (create — "create a new order"), PUT/PATCH (update), DELETE (delete).
  • URL (address) — where we're sending the request, for example example.com/api/orders.
  • Headers — metadata: data format, an authorization token (who we are).
  • Body — the data we're sending, typically for POST. Often in JSON format — a simple text "key: value" form.

What a response is made of

The server responds, and in the response the key things for us are:

  • Status code — a short summary. Worth remembering by group:
    • 2xx (200, 201) — success, everything is fine.
    • 4xx (400, 401, 403, 404) — an error on our side: bad request, not authorized, access denied, not found.
    • 5xx (500) — an error on the server. Almost always a bug.
  • Response body — the actual data (usually JSON): a list of orders, an error message, a created object.

Checking an API comes down to the same thing as everywhere else: comparing the actual response (status + body) with the expected one.

First steps in Postman

Postman is a free app where you build a request with the mouse: choose a method, enter an address, optionally add a body and headers, click Send — and get a response with a status code and body.

A simple practice scenario:

  1. Choose the GET method, enter the address of an open training API (there are free ones online — search for "public test API") and click Send. Look at the status 200 and the data in the response.
  2. Try POST — send a body with new data, see status 201 and the created object in the response.
  3. Make a deliberately wrong request (a non-existent address) and see status 404.

This way you'll feel the "request → response → status" connection in practice. What to check in the responses — the same positive and negative scenarios you use elsewhere: correct data, empty data, invalid data, no authorization.

Where this applies

API testing is an important skill by the time you reach a mid-level role. On a project you'll check requests directly when you need to try many variations quickly, separate a server bug from a UI bug, or start testing before the screens are ready. And combined with the Network tab this gives you the full picture: there you see what request the page sends, and in Postman you can replay it by hand and play with the data.

Where beginners stumble:

  • Being afraid of the word API and avoiding it, missing a powerful and fast way to test.
  • Not understanding status codes. At least the groups 2xx/4xx/5xx need to be second nature — they immediately tell you where to look.
  • Only checking successful requests and forgetting negative cases: without authorization, with an empty body, with invalid data.

What to learn next. A request went out and the server saved something — but how do you confirm it saved correctly? Look in the database. That's covered in SQL for testers.