Types of API Testing, and Where Each One Fits

Most articles about the types of API testing read like a taxonomy exercise with no reader in mind. This one is organised around a more useful question. What class of defect does each method catch, and what will it happily let through.

If you only read one thing here, read the column that says what each method misses. Every method has such a gap, and those gaps are where production incidents come from.

The seven methods at a glance

Method	Catches	Misses	Typical place
Functional	Wrong status, wrong values, missing headers, broken error paths	Shape changes nobody asserted on	Pull request
Contract	Renamed fields, changed types, dropped required properties	Values that are wrong but well-formed	Pull request
Workflow	State that does not carry between calls, broken multi-step flows	Anything one call already proves	Pull request or nightly
Data-driven	Edge values, boundary conditions, per-input behaviour	Interactions between separate calls	Pull request or nightly
Performance	Latency regressions, error rate under concurrency, resource limits	Correctness of any kind	Nightly or pre-release
Security	Authorization gaps, injection surfaces, misconfiguration	Business-logic abuse a scanner cannot model	Nightly, plus a light pass per pull request
Production monitoring	Real outages, contract drift after deploy, stale data	Anything before the release	Continuously

Functional tests

A functional test sends one request and asserts on the answer that comes back. It is the method everything else builds on, and it is also the one most likely to be done badly.

Done well, it asserts the status code, the two or three fields that carry the behaviour under test, and the response header that matters. Done badly, it either compares the whole body, which turns every unrelated change into a red run, or it asserts only that the status was 200, which passes while the payload degrades into nonsense.

Functional tests are also where negative cases live. An API that returns the right thing for good input and something undefined for bad input is only half tested, so the 400, the 401, the 403 and the 404 deserve cases of their own. Read more in functional tests.

Contract tests

A contract test validates the response against the specification instead of against an expectation written into the test. That single change moves the oracle outside the test, so a field that changed type fails without anyone touching the test file.

The method needs a specification to exist, and that is the one prerequisite the other methods do not have. In exchange it catches the entire class of defect that functional tests structurally cannot see, because a functional test only knows about the fields its author named.

Contract testing is often confused with integration testing, and the two answer different questions. Contract testing vs. integration testing works through the distinction and both sides of the consumer and provider relationship.

Workflow and scenario tests

Real APIs are used in sequences, and the sequence is where the interesting defects hide. A client registers, logs in, creates an order and then reads it back, and each step depends on something the previous step produced.

A workflow test chains those calls and passes values between them, so it catches the defects that only appear in combination. A resource is created but cannot be read back, a token is issued but not accepted, or an identifier changes format between the create response and the read path. None of those show up when each endpoint is tested on its own.

The cost is that workflow tests run slower and break more often than single-request tests, so use them for the flows that carry the business and not for everything you own. See workflow and scenario tests.

Data-driven tests

Some questions are about inputs, not about the endpoint. Whether a price field accepts zero, whether an email validator rejects the awkward cases, or whether a search behaves at its page-size boundary. All of these are the same request repeated with different values.

Writing one test per value produces a suite that nobody maintains. A data-driven run writes the case once and iterates over a table of rows instead, and the expected outcome can be a column too, so one case asserts different results for different inputs.

Running one case across a table of rows is the cheapest way there is to raise coverage of edge cases. The mechanics are covered under test data.

Performance tests

Performance testing answers a question correctness testing never asks. How does the API behave when many callers arrive at once. Three traffic profiles cover most of what a team needs to know.

Profile	What it does	What it answers
Load	Sustained traffic at expected volume	Does the service hold its latency budget on a normal day
Stress	Traffic raised until something gives	Where the ceiling is, and how the service fails when it gets there
Soak	Moderate traffic over a long period	Whether memory, connections or caches degrade over hours

The measurement that matters is the p95 and not the average, because the average hides the tail that users actually notice. A run that averages 120 ms with a p95 of 3 seconds is a bad run, and the average alone will not say so. See performance testing.

Security tests

Security testing overlaps with functional testing at one point only, namely the authorization check. Everything else it does is different in kind, because it probes for behaviour nobody intended instead of behaviour someone specified.

Automated scanning covers the mechanical categories well, and those categories are where most real breaches start. They are missing authorization on an object or a function, input handling that accepts what it should reject, misconfiguration, and information exposure. It cannot model your business rules, so a scanner will never notice that a refund endpoint lets a user refund somebody else's order if both users are legitimately allowed to call it.

That gap is why authorization deserves hand-written negative tests alongside the scanner. API security testing covers both halves.

Production monitoring

Every method above runs before or during a release, which means none of them watches the live service. Production monitoring is the only one that observes the thing your customers are actually using.

Production monitoring does two jobs at once, and most teams only collect the first. Synthetic checks answer whether the service is up and how fast it is responding, and contract validation on those same checks answers whether the deployed service still matches the contract it is supposed to serve. The second job is the one most teams skip, and it is the one that catches drift.

See testing in production for monitors, drift events and alerting that people do not learn to ignore.

Choosing what to build first

If you are starting from nothing, build in this order, because each step makes the next one cheaper.

1. Functional tests for the happy path of every endpoint you own, generated from the specification where one exists.
2. Contract validation on those same cases, which costs almost nothing once the cases exist.
3. Negative cases for authorization and validation, because those are the failures that reach customers.
4. Workflow tests for the two or three flows that carry your revenue.
5. A CI gate, so all of the above runs without anyone remembering to.
6. Monitoring and drift detection on the deployed environment.
7. Performance and the full security profile on a schedule.

Teams that invert this order tend to end up with an impressive load-test setup and no idea at all when a field quietly changed type.

In Routebase

The methods above are not separate tools in Routebase. A test case is one HTTP request with declarative assertions, and the method is decided by what you do with that case.

Link the case to a designed endpoint and it becomes a contract test, because a Schema Validation assertion checks the live response against the endpoint's documented schema. Add the case as a step in a scenario and it becomes part of a workflow, passing extracted values to later steps. Attach a data set to the suite and the same cases run once per row. Flip the runner from functional to performance mode and the same suite runs a load profile with iterations, threads and a per-case breakdown. Security scanning runs against the same environment through scan profiles, and monitors keep validating the deployed service afterwards.

One request, written once, serving whichever method you need. The Test Suites guide covers cases, assertions and run modes in detail.