In this guide 6 sections
API testing sends requests straight to the software’s back end and checks what comes back: status codes, payload fields, authentication, error messages and the rows written to the database. A screen can display a tidy number while the API underneath has sent or stored the wrong one.
What sits below the screen
When you tap Place Order, the screen calculates nothing important. It sends a request to an API, which is a set of server addresses that accept and return data. The server then prices the basket, checks stock, writes the order and replies. The screen only draws that reply.
Testing the screen alone is like judging a restaurant by reading the menu. The menu looks fine. Nobody has tasted the food. That is the gap. API testing skips the menu and talks to the kitchen directly, using a tool such as Postman or a scripted runner that fires hundreds of requests in a minute.
What an API test actually checks
A tester sends a request with a chosen payload, usually JSON, and inspects the response. Is the status code right: 200 for success, 400 for malformed input, 401 for no login, 403 for a forbidden record, 404 for a missing one? Are the fields present, spelled correctly and of the right type? Each answer is a small pass or fail.
Then the tester checks the effect. If an order was created, does the database hold exactly one row, with the right customer, the right tax line and the right stock reduction? A reply that says success while no row was written is a classic fault. The screen can never reveal it.
- Status code for each outcome
- Field names, types and required values
- Response time on a normal request
- Rows written to the database
- Stock and ledger side effects
Why an app can look fine and still be wrong
Take a discount code that the screen applies in the browser. The basket shows the lower total, yet the API recalculates from the full price list and stores the old amount. The customer sees one number and pays another. Only a check against the stored order catches it.
Screens also hide rounding errors, currency conversion, a missing tax band and double-clicked submissions, and they can show a cached copy of yesterday’s basket. The API reply is the source of truth. Every other screen, mobile app and partner system reads it.
Security and error handling live at this layer
The screen hides buttons from people who may not use them, but hiding is not refusing. The API must refuse the request itself. A tester sends the call without a token, with an expired token and with another user’s order number, and expects a clear refusal each time.
Error handling matters too. When the payment gateway times out, does the API return a clear message and leave no half written order? Or does it print a stack trace with a server folder path in it? Those answers show how the software behaves on a bad day.
- Call without a login token
- Expired and tampered tokens
- Another customer’s record number
- Oversized and malformed input
- Gateway or third party timeout
How to ask for it without being technical
You do not need to read JSON. Ask the testing team for a list of the API calls covered, a pass or fail for each and the defects found. Ask which calls change money or customer data. Ask whether those calls got negative tests as well.
Request one worked sample, a failed call shown with its request, its reply and the fix that followed. If the tester can explain it in plain words, the testing is real. Add the covered calls to your acceptance sheet before the next release.
API test coverage tracker
The table gives each API call its own row. Columns: call name, what it does, touches money or personal data, positive test, negative test, login rule checked, database effect checked, result and tester. A strip across the top counts calls covered against calls listed.
Open a blank worksheet to printQuestions owners ask
Is API testing the same as unit testing?
No. Unit tests check small pieces of code in isolation. API tests call the running service the way another system would, so they catch faults in how the pieces fit together.
Do I still need screen testing?
Yes. Screens can break layouts, buttons and forms that the API never sees. The two layers cover different faults, and good teams test both.
Can API tests be automated?
Largely, yes. Scripts can replay hundreds of calls after each build and flag any change in the reply. New or unusual calls still deserve a person’s eye.
When should API testing start?
As soon as the first endpoint exists, often before the screens are built. Finding a wrong total early is far cheaper than finding it after launch.