What API testing covers
An API is a contract: given this request, the provider promises this response. API testing checks that promise from several angles. Does each endpoint return the documented status code and body? Does it reject bad input? Does it hold up at peak traffic? Does it refuse callers who should not get in? And when the code changes, does it still behave the way existing clients expect?
Because APIs have no screen, tests talk to them in the same language clients do: HTTP requests, gRPC calls or GraphQL queries (compared in REST vs GraphQL vs gRPC). That makes API tests faster and more stable than UI tests, and it means the same suite can run on a laptop, in CI and against a staging environment.
The seven types of API testing
Unit tests
Unit tests exercise one handler, validator or serializer in isolation, with dependencies replaced by fakes. They are cheap, fast and precise about where a bug lives. They say little about whether the pieces work together or whether the wire format is what clients expect.
Contract tests
Contract tests check the agreement between a provider and its consumers. In consumer-driven contract testing, each consumer records the interactions it depends on, and the provider's build verifies every change against those records. Schema validation against an OpenAPI document is a lighter form of the same idea. Contract tests catch structural breaking changes before deployment.
Integration tests
Integration tests run the API with its real dependencies: database, cache, queue, other internal services. They catch misconfigured connections, bad queries and serialization mismatches that unit tests hide behind fakes. They are slower and need environment management, so teams keep them focused on the riskiest paths.
End-to-end tests
End-to-end tests drive a complete user journey across several APIs, such as signing up, creating an order and receiving a webhook. They give the most realistic signal and are the most brittle, so a small number of critical journeys is usually worth more than hundreds of flaky ones.
Load and performance tests
Load tests send sustained or increasing traffic to find latency limits, throughput ceilings and failure modes such as connection exhaustion. Variants include stress tests (beyond expected peak), soak tests (long duration, to expose leaks) and spike tests (sudden bursts). Run them against an environment sized like production, or the numbers will mislead you.
Security tests
Security tests probe authentication, authorization, input handling and configuration. They range from automated scanners that fuzz parameters to manual tests that try to read another user's objects by changing an ID. The OWASP API Security Top 10 is a useful checklist of what to probe.
Replay tests
Traffic replay testing captures real requests, sends them to the current and candidate versions of a service, and diffs the full responses. It answers a question no other layer does well: for the traffic we actually serve, did behavior change? It is the layer that catches semantic breaks, such as a value switching units while the schema stays the same.
API testing tool categories
Rather than chase a single best tool, pick one per job:
- HTTP clients and collections for exploratory and manual testing, which often double as shareable request libraries.
- Test frameworks in your language (the same runner you use for unit tests) with an HTTP client library, for assertions that live next to the code.
- Contract testing frameworks such as Pact for consumer-driven contracts, and schema validators for JSON Schema and OpenAPI.
- Spec diff tools that compare two OpenAPI documents in CI. See OpenAPI diff.
- Mock servers that serve responses from a specification so consumers can test before the provider ships. See API mocking.
- Load generators such as k6, JMeter, Gatling or Locust, scripted in code so tests are versioned and repeatable.
- Security scanners and fuzzers such as ZAP, plus schema-aware fuzzers that generate hostile inputs from a spec.
- Traffic capture and replay tools that record requests, redact sensitive data and diff responses between versions.
A layered API testing strategy
Each layer is cheap at catching one kind of problem and expensive or blind at others. A strategy that works for most teams:
- On every commit: unit tests and schema validation. These should finish in minutes.
- On every pull request: contract verification against every known consumer, plus a spec diff that fails on breaking changes.
- Before merge or deploy: integration tests for the riskiest paths and a replay run against a representative traffic sample, so behavioral changes surface with the exact request that diverged.
- Before release: a handful of end-to-end journeys in staging.
- On a schedule: load tests and security scans, plus targeted runs whenever a change touches capacity or auth.
- In production: synthetic checks and API monitoring, because the only environment that is exactly like production is production.
Write down which layer owns which risk. When an incident slips through, add the test to the cheapest layer that could have caught it.
Where mocks help and where they hurt
Mocks make tests fast and deterministic, and they let consumers build before the provider is ready. The cost is that a mock is a snapshot of what someone believed the API did at one moment. When the real API changes, the mock does not, and the tests keep passing against the past.
Keep mocks honest by generating them from the same specification the provider publishes, verifying them with contract tests, and checking real behavior with replay before you trust a migration. That matters most during an API migration, where the whole point is that behavior has changed.
Common gaps in API test suites
- Only happy paths. Error responses, validation failures and timeouts are part of the contract and deserve tests.
- No authorization tests. Checking that user A cannot read user B's objects is one of the highest-value tests you can write.
- Pagination and limits. Empty pages, the last page and maximum page sizes are classic edge cases. See pagination.
- Idempotency. Retrying a request with the same key should not create a duplicate. See idempotency.
- Coverage is not usage. The calls your customers make most are often not the ones your tests exercise most.
That last gap is why teams that verify migrations with recorded real traffic, the approach Releo uses to gate every migration pull request, find problems their suites miss.
Frequently asked questions
What is API testing?
API testing verifies that an API returns correct responses, handles errors and bad input properly, performs under load and enforces security, by sending requests to it directly instead of going through a user interface.
What are the types of API testing?
The main types are unit, contract, integration, end-to-end, load and performance, security, and replay testing. Each catches a different class of problem, so mature teams combine several of them.
What is the difference between API testing and contract testing?
Contract testing is one type of API testing. It focuses only on whether the provider still honours the requests and responses its consumers depend on, while API testing as a whole also covers logic, performance and security.