What Is API Testing? A Practical Definition

API testing means sending a request straight to an API’s endpoint and checking what comes back, without a browser or a mobile screen in the loop. A test picks an HTTP method, points it at an endpoint, and checks the status code and the response body. That single mechanic covers five commonly cited types: functional, integration, load and performance, security, and contract testing, and it fits into a much older idea of organizing tests by scope, with a different tool suited to each layer. The rest of this guide works through each part: the definition, where it fits, the five types, how one test run works, and where to go next.

What API testing is (and what it is not)

API testing checks an API directly: a test sends a request to a specific endpoint and inspects the response, instead of clicking through a finished page or a mobile screen to get to the same result. The category’s own top-ranking guides describe the same core idea: Postman, GeeksforGeeks, IBM and Keploy each define API testing as verifying that the API works correctly or as intended. A synthesis of the search results adds the detail that this happens at the business logic layer, bypassing the user interface entirely.

That framing rules out a common shortcut. Opening Postman, building a request by hand, and clicking Send is one way to exercise an endpoint, but the tool is not the definition. The same check can run from a command line, a CI job, or a generated suite that never opens a graphical client at all; what makes it API testing is where the check happens, at the interface, before any screen is built from it, not which client sent the request.

That placement is also why teams reach for it early. An API is usually built before the interface that will sit on top of it, and testing it directly is how developers find and fix core logic bugs early, before the UI work that depends on it even starts. And because there is no page to build and no browser to drive, one of these checks typically finishes in a fraction of a second, which is why teams can run many of them on every change without slowing anything down.

Where API testing sits next to unit tests and end-to-end tests

API testing is not the only layer teams run, and it helps to know what sits on either side of it. A unit test checks one function or class by itself, with everything around it faked or removed. An end-to-end test drives the whole system the way a person would, including whatever interface sits on top: a browser, a mobile app, a form. An API test sits between the two: it runs a real request against a real, running service, but it skips the interface, so it costs more than a unit test and less than a full end-to-end run.

Teams commonly organize their automated checks by scope this way, from smallest and fastest to broadest and slowest, matching a different kind of tool to each layer. A related, narrower discipline lives inside the API layer itself: contract testing, which checks that a service consumer and a service provider agree on the shape of a request and its response, without needing to run either one in full. That check earns its keep when two teams own the two sides of an integration and neither wants to stand up the other’s service just to test against it.

None of these layers replaces another. A passing API test says nothing about whether the sign-up form on top of the API displays correctly, and a passing end-to-end test can hide an API bug that the UI never happens to trigger, because the two layers exercise different paths through the same system.

The five commonly cited types of API testing

Five types come up again and again in guides to this category, and knowing them by name gives you a vocabulary for placing any tool, or any article on this site, against the job it actually does.

Functional testing. Does the endpoint return the exact data it was asked for, under normal conditions? This is the baseline check: send a valid request, confirm the response matches what the API contract promises. It is usually the first type a team writes, because it is the type that maps directly onto “does the feature work,” and most of the requests a person would send by hand fall into this category.

Integration testing. Does the API talk correctly to the other services, databases, and third-party systems it depends on? A function can pass in isolation and still break the moment it calls a real downstream service with a real network in between. This is the type that catches a change on one side of an integration before it reaches the other, which matters most in a system built out of several services owned by different teams.

Load and performance testing. How does the API hold up under heavy traffic: does it stay responsive, does it stay fast, does it stay up? This site’s guide to load testing with realistic, multi-step flows covers this type in depth, including why a single-endpoint test misses the failures a real user journey finds, and why the order and weight of the calls in that journey change what the test actually proves.

Security testing. Do authentication, authorization, and data handling stay correct under input designed to break them, in addition to input that behaves normally? This type asks the API to fail safely instead of failing open, which a purely functional check, built around valid input, has no reason to try.

Contract testing. Does the shape of the request and the response still match the agreed schema as both sides of an integration keep changing? This is the type that lets two teams change their own service without breaking the other’s tests, described in more detail above. It runs against the schema alone, not against a live counterpart, which is what makes it fast enough to run on every change instead of only before a release.

These five are not exclusive. Most real suites mix functional checks with a smaller number of load, security, and contract checks, and treat each type as a different question to ask about the same endpoint, not a separate tool to buy for each one. A new API usually earns functional coverage first and adds the other four as the integration surface, the traffic, and the number of consumers grow. Some lists count nine or more types; a longer count usually comes from splitting this same handful into finer categories instead of finding new ones, so treat any bigger number as that source’s own way of slicing the same underlying checks.

How an API test actually runs, step by step

A single API test follows the same shape almost every time, whichever type it belongs to. Walking through one run end to end shows what a tool is actually doing under whatever interface it presents.

Send the request. The test picks an HTTP method that matches the action it wants to check: GET to read something, POST to create it, PUT or PATCH to update it, DELETE to remove it, and sends it to a specific endpoint with whatever headers, authentication, and body the endpoint expects. Building that request is the one step every type of API testing shares; a security test and a functional test can send the exact same request and differ only in what they check once the response arrives.

Check the status code. The response carries a status code, and the test checks it matches what that request should produce: 200 for a successful read, 400 for a request the server rejected as malformed, 401 for one missing valid authentication, 500 for a failure on the server’s own side. A test that only checks whether something came back misses the difference between a real success and a server quietly failing, and the status code is usually the first assertion a test makes because it is the cheapest one to check.

Check the payload. Beyond the status code, the test inspects the response body, usually JSON, sometimes XML, and confirms the fields, values, and structure match what was asked for. A status code of 200 with the wrong data inside is still a bug, and this is the assertion that catches it: a renamed field, a missing item, or a value in the wrong format all pass the status check and fail this one.

Check performance, when it matters. Some tests also record how long the response took, which is the same request and response cycle with a clock on it: the same mechanic load and performance testing runs at a much larger scale, against many requests at once instead of one.

Read the result. A pass means every assertion in that request held: the right status, the right payload, and, where checked, an acceptable response time. A fail means at least one assertion did not, and a useful test reports which one, so the fix targets the actual broken piece instead of the whole endpoint. That single request-assertion-result loop is what every tool in this category automates; what changes between them is how the request gets built and how many of them run at once.

From one manual request to tests that run on every pull request

Most teams start exactly where this guide started: one request, built and sent by hand, usually in a collection-based client, to check that one endpoint works. That is a fine way to confirm a single endpoint today. It is not a plan for keeping hundreds of endpoints checked as the API keeps changing.

The problem that shows up first is maintenance. A hand-written collection is a snapshot of the API at the moment someone wrote it, and every renamed field, new endpoint, or changed response drifts the collection further from the service it is meant to check. This site’s guide to alternatives to hand-writing Postman collections works through what replaces that manual step, and the follow-up on keeping API tests current with the code covers the mechanisms that catch the drift itself.

One answer to that drift is to stop authoring the requests at all and generate them instead, either from a specification the API already publishes or from the traffic the API is already handling. Those two paths trade different setup costs for different guarantees, and this site’s comparison of tools that generate tests from traffic and its head-to-head on AI-generated tests go through both in detail. A broader roundup, Best AI Tools for API Test Generation, lines up more of the generators against each other side by side.

The step after generation is where the test runs. A test that only exists on someone’s laptop protects nothing; the same request-status-payload check from the previous section earns its keep when it runs automatically on every pull request, before the change merges instead of after a person notices something broke. That is also the point where the five types from earlier in this guide stop being separate exercises and start being separate jobs in the same pipeline: functional and contract checks on every change, load and security checks on a slower schedule that still runs before a release. A working workflow file for the pull request half is in running API tests on every pull request.

Stresseur fits into this progression as the generation branch: it learns how an API is actually used and creates the tests each change needs, keeping them current on every pull request instead of left for someone to update by hand. It is one option in this path, at early access today, not a replacement for understanding what these tests check and why, which is what the rest of this guide covers.

API testing means checking an API directly, at the request and response level, before any interface is built on top of it. The mechanics are the same whichever of the five types is running: send a request, check the status code and the payload, and read the pass or fail against exactly what that assertion tested. Where you go next depends on which part is costing you time now: hand-written collections that go stale, tests that need to survive real traffic, or load that only shows up in a multi-step user flow, and this site’s other guides work through each of those in turn.