Types of API Testing: 12 Kinds Explained With One Example

The main types of API testing are functional, validation, negative, integration, contract, end-to-end, security, performance (load, stress, spike, soak), reliability, fuzz, regression and smoke testing. They fall into three families: tests that check the API works, tests that check it holds up under pressure, and tests that check it is safe.

Below, each type gets a plain definition, what it catches, when to use it and its limits. Then all of them are applied to one example endpoint, so you can see how a real API test plan is built.

An API (application programming interface) is the contract one program offers another: send this request, get that response. In API testing you skip the screen and send requests straight to the endpoint, then check the status code, response body, headers, response time and side effects (for example, a row created in the database).

Because there is no UI, API tests run fast and break less often than UI tests, which is why most teams put far more of them in their suite. If you are new to the basics, start with our API testing tutorial, then come back here.

1. Functional testing

Sends valid requests and checks the API returns the right result. For a POST /orders that means: status 201 Created, an order id in the body, the right total, and the order actually saved. This is the base layer; every other type assumes it passes.

Limit: it proves the documented behaviour, not behaviour nobody thought to document.

2. Validation testing

Checks the shape of the response: required fields present, correct types (total is a number, not a string), date formats, enum values, headers such as Content-Type: application/json. A JSON Schema assertion covers most of this in one line, and catches the "a developer renamed a field" class of bug.

3. Negative testing

Sends requests that should fail: missing fields, wrong types, values out of range, unknown ids, expired tokens. The API should return a clear 4xx error (usually 400, 401, 403, 404 or 422) with a useful message, and never a 500 or a stack trace. Status code meanings are defined in RFC 9110.

Negative tests are where boundary value analysis and equivalence partitioning earn their keep; see worked test scenario and test case examples for how to derive them.

4. Integration testing

Runs the API against its real dependencies (database, message queue, payment sandbox) and checks they cooperate: the order is written, the stock is reduced, the event is published. It catches configuration and wiring faults that mocks hide.

Limit: slower and more fragile because it depends on shared environments.

5. Contract testing

Checks that a provider API still honours what its consumers rely on, without running both together. In consumer-driven contract testing, each consumer records the requests it sends and the fields it reads; the provider's build replays those expectations. Our Pact consumer and provider guide walks through a full example.

Contract vs integration: contract tests ask "do we still agree on the format?" and run fast in each team's own pipeline. Integration tests ask "does the whole thing actually work together?" You usually want both.

6. End-to-end API testing

Chains several calls into one business flow: create user, log in, add to cart, place order, check order history. It proves the journey works, but a failure tells you less about where the problem is, so keep these few and focused on critical paths.

7. Performance testing

Performance is an umbrella for several distinct tests. Choose by the question you need answered:

Report percentiles (p95, p99), not just averages: an average of 200 ms can hide 1 in 20 users waiting several seconds. For tooling and scripts, see the performance testing guide.

Limit: results only mean something on an environment that resembles production. Never run them against a shared environment without warning the team.

8. Reliability testing

Checks behaviour when things go wrong around the API: a dependency times out, the database restarts, the network drops packets. Good APIs retry safely, time out instead of hanging, and return a clear 503 rather than corrupt data.

9. Fuzz testing

Generates large numbers of random or malformed inputs (huge strings, odd Unicode, nulls, nested JSON) to find crashes. Schema-driven fuzzers such as Schemathesis read your OpenAPI file and create the inputs for you, which makes fuzzing cheap to start.

10. Security testing

For APIs the biggest risk is usually authorisation, not clever hacking. Item one of the OWASP API Security Top 10 (2023) is Broken Object Level Authorization: user A changes an id in the URL and reads user B's order.

A practical checklist:

• Authentication: no token, expired token, tampered token all get 401.
• Object-level access: user A requesting user B's resource gets 403 or 404, never the data.
• Function-level access: a normal user calling an admin endpoint is refused.
• Input handling: injection payloads in fields and parameters are rejected, not executed.
• Data exposure: responses do not leak fields the client does not need (password hashes, internal ids, other users' emails).
• Rate limiting: repeated login attempts are throttled.

Token handling has its own pitfalls; our guide to testing JWT authentication covers them with code.

11. Regression testing

Re-runs existing API tests after every change to confirm nothing that worked has broken. In practice this is your functional, validation and negative suite running in CI on each merge. It is less a separate test and more a habit.

12. Smoke testing

A handful of fast checks run right after deployment: health endpoint returns 200, login works, one key read works. If smoke fails, stop; deeper testing on a broken build only produces noise.

You will also see UI-less "API monitoring" (scheduled smoke checks in production) and interoperability testing (checking clients in different languages or versions) listed as types. They are useful, but they are variations on the twelve above.

Illustrative example on a fictional API. Endpoint: POST /orders. A signed-in customer sends a product id and quantity; the API checks stock, charges a saved card through a payment service and returns the order.

POST /orders
Authorization: Bearer <customer-token>
Content-Type: application/json

{ "productId": "P-1001", "quantity": 2 }

201 Created
{ "orderId": "O-5531", "status": "PAID", "total": 1998.00, "currency": "INR" }

Notice the reliability row: a timeout that still creates a PAID order means a customer is charged without knowing. That single check is often worth more than dozens of happy-path tests, and it only appears when you think in types.

1. Functional, validation and negative on every endpoint. Cheap to write, fast to run, find most defects.
2. Security (authorisation) on anything touching user data. One missing ownership check can expose every customer.
3. Integration and a few end-to-end flows for money, sign-up and other critical journeys.
4. Contract once several teams or apps depend on the same API.
5. Performance, reliability and fuzz when traffic, uptime or public exposure make them a real risk.
6. Wire everything into CI so it becomes your regression suite, plus a short smoke set after deploys.

• Asserting only 200: a response can be 200 and still have the wrong total.
• Skipping negative tests because "the frontend validates it" (attackers and other clients skip your frontend).
• Testing authorisation with a single user account, which can never reveal cross-user access.
• Reporting average response times instead of percentiles.
• Hardcoding ids and tokens so tests fail on every new environment.

"I group API testing into three families. To check it works: functional, validation, negative, integration, contract and end-to-end tests. To check it holds up: load, stress, spike, soak, reliability and fuzz testing. To check it is safe: security testing, especially authentication and object-level authorisation. Regression and smoke runs keep it all working over time. I start with functional and negative tests, then add the others based on risk."

Likely follow-ups: What is the difference between contract and integration testing? Which status code for a validation error? How would you test that one user cannot see another's data? More practice in our API testing interview questions.

How many types of API testing are there?

There is no official number. Lists range from about seven to fifteen depending on whether sub-types such as load and stress are counted separately. Focus on what each type checks rather than the count.

Is API testing manual or automated?

Both. Exploring a new endpoint in a tool like Postman is manual; the functional, negative and regression checks you keep are usually automated. See our Postman API testing tutorial for both styles.

Does GraphQL need different types of testing?

The same families apply, but details change: most responses return 200 with errors in the body, and query depth limits matter for security. Our GraphQL API testing guide covers the differences.

Reading about types only goes so far. Open the free API Playground and try them on a practice API: send a valid request (functional), break the body (negative), and try reading another workspace's data (security). If you want a structured path from there, the API testing course builds an automated suite step by step. Got a type you are unsure how to test? Ask it in the QA community.