Types of API Testing: The Five Kinds Explained

The main types of API testing are functional, integration, contract, load and security testing. Each type asks a different question about the same endpoint: does it answer correctly, does it work with its neighbors, does it keep its promises, does it hold up under traffic, and does it fail safely. This post takes them one at a time.

The five types at a glance

API testing sends a request to an endpoint and checks what comes back. The types differ in what they check, not in how the request is sent.

• Functional: does the endpoint return the right data for a valid request?
• Integration: does the API work with the database and services behind it?
• Contract: does each request and response still match the agreed schema?
• Load: does the API stay fast and stay up under heavy traffic?
• Security: do authentication and authorization hold up against bad input?

Some lists count nine or more types. A longer list usually splits this same handful into finer pieces.

Functional testing

Functional testing asks whether the endpoint returns the right data under normal conditions. You send a valid request and confirm that the response matches what the API promises.

This is usually the first type a team writes, because it maps onto “does the feature work.” A good functional test checks the exact status code and the body fields you rely on, and treats “something came back” as too little.

A create deserves one more check. After a POST, read the item back. A success code alone does not show that the item was stored, so a later read is the check. Stresseur’s generated flows do this: after a create, a later read of the list or page must hold the new id, or a value the user typed.

To write your first one, follow How to Test an API. The longer version is REST API testing, step by step.

Integration testing

Integration testing asks whether the API works with the database, services and third-party systems behind it. A function can pass on its own and break the moment it calls a real neighbor. This type catches a change on one side of a connection before it reaches the other.

The usual shape is a multi-step flow. Log in, take the token from the response, create an order with it, then list the orders and look for the new id. Each step depends on the one before, so the flow fails at the step where the connection breaks.

Stresseur records how an API is really used during development and turns those flows into YAML tests. Integration Testing Examples for a REST API walks through four of them from request to assertion. For the definition, read What Is Integration Testing?.

Contract testing

Contract testing asks whether the shape of each request and response still matches the agreed schema as both sides change. It lets two teams change their own service without breaking the other’s. Because it runs against the schema and not a live service, it is fast enough to run on every change.

Two approaches are common. Consumer-driven tools start from what the calling service expects. Pact, for one, is a code-first tool for testing HTTP and message integrations using contract tests. Schema-first tools start from the API’s written description. Schemathesis describes itself as property-based API testing for OpenAPI and GraphQL schemas.

The two answer different questions. A schema-first tool checks a service against its own schema. A consumer-driven tool checks what a particular caller needs from it. For the steps, see Turn an OpenAPI Spec into Contract Tests. To pick a tool, read Best Contract Testing Tools for Microservices.

Load testing

Load testing asks whether the API stays fast and stays up under heavy traffic. Many virtual users run the same requests at once while the test tracks response times and errors.

Load testing is a family of its own. The k6 test types guide describes a load test as one that assesses how the system performs under expected normal conditions. A stress test assesses how it performs at its limits, when load exceeds the expected average. The load testing guide linked at the end of this section covers the other test types.

The traffic should look like real use. A single endpoint under load misses what a full user journey finds, so the best load scripts reuse a functional flow. In Stresseur, any recorded flow can also run as a load test. The API testing page shows how a flow is recorded. The full guide is Load Testing: A Practical Guide for APIs.

Security testing

Security testing asks whether authentication, authorization and data handling hold up under input built to break them. It asks the API to fail safely, with a 401 or a 403, and never to fail open.

A functional test is built around valid input, so it has no reason to try these cases. A security test sends a request with no token, a token that should not work, or another user’s id, and checks that the answer is a refusal. The same request that passes a functional check can be sent without credentials and must then fail. You can test multi-step flows with auth tokens the same way, with an expired or altered token that should get a 401 or 403. This post does not cover dedicated security scanners.

Which type to write first

Start with functional tests. A new API usually gets functional coverage first and adds the other types as its traffic and its number of clients grow.

The types overlap. Most suites mix many functional checks with fewer load, security and contract checks. A flow that logs in and creates an order is a functional test, an integration test and the start of a load script at once. Write it once, then ask which question you still cannot answer.