When a team tells me they do API testing, I have learned to ask which kind. Almost always the answer, once you dig in, is functional testing. They send requests, check responses, confirm the endpoints return what they should. That is real and useful, but it is one type out of several, and the incidents that hurt most tend to come from the types nobody set up. The phrase covers far more ground than the practice usually does, and the gap between the two is where a lot of production surprises live.

"We do API testing" usually means one thing

Functional testing is the default because it is the most obvious. Does this endpoint return the right response for this input. It is easy to start, easy to reason about, and it genuinely catches a lot of real problems early. The trouble is not that functional testing is weak. It is that it quietly becomes the entire working definition of API testing in a team's head. Once that happens, everything it does not cover stops feeling like a gap and starts feeling like it does not exist. The map becomes the territory, and the parts of the territory that are not on the map get no attention at all.

The types that get skipped

The full set of types of api testing covers a much wider range of failure than functional checks alone. Integration testing asks whether services actually cooperate correctly, not just whether each one behaves in isolation. Contract testing asks whether a change on one side quietly breaks a consumer on the other. Load and performance testing ask what happens when traffic climbs past the comfortable range you developed against. Security testing asks how the endpoint can be abused by someone who is not playing nicely. Each of these targets a class of defect that functional testing cannot see, because functional testing is asking a different and narrower question.

It helps to think of each type as a specific fear made concrete. Integration testing is the fear that two correct services still misunderstand each other. Contract testing is the fear that a field you renamed was load bearing for someone downstream. Load testing is the fear that the thing works fine until the morning everyone shows up at once. Security testing is the fear that the input you assumed was well behaved arrives hostile. Named that way, it becomes obvious that no single type answers all of them.

Why the gaps stay invisible

The reason these blind spots persist is that functional tests stay green while the uncovered failures accumulate somewhere else entirely. Your suite passes, the dashboard is reassuring, and everyone moves on. Then an integration between two teams breaks in a way neither team's tests could catch, or a schema change takes down a downstream consumer that nobody knew depended on the old shape, or an endpoint that was instant in development falls over under a real traffic spike, or someone discovers an authorization hole that was there the whole time. None of those would have turned a functional suite red, so the suite handed you a confidence it was never entitled to give. Green stopped meaning safe and started meaning only that the one type you happened to run still passes.

Match the missing types to your real risk

The answer is not to do all of them equally. Trying to be thorough across every type is a reliable way to spread a team thin, ending up with shallow coverage everywhere and depth nowhere. The useful move is narrower. Look honestly at which class of failure would actually hurt you, and add the type that catches it. If you integrate heavily with other services and teams, contract and integration testing earn their place before anything else. If you run a public, high traffic API, load and security climb the list because that is where your exposure concentrates. If you are a small internal tool with three users, functional testing genuinely might be enough, and pretending otherwise just wastes effort. The point is not to collect every type like a checklist. It is to stop assuming functional testing covers risks it was never designed to touch.

Adding a type is cheaper than the incident

Teams resist this because each new type feels like a new project with its own tooling, its own learning curve, and its own maintenance burden. In practice, the first useful increment is much smaller than that. A handful of contract tests on the two or three interfaces that other teams actually depend on. One basic load test against the single busiest endpoint. A focused pass of security checks on the routes that touch authentication and money. None of these requires boiling the ocean, and each closes a specific, identifiable gap. Measured against the outage it prevents, the cost of adding one targeted type is almost always trivial. The expensive path is the one where you find out which type you were missing by living through the failure it would have caught.

Start with one, then reassess

If you take one thing from this, let it be a sequence rather than a mandate. Keep your functional coverage, since it is doing real work. Then pick the single type that maps to your most likely and most painful failure, add a small amount of it, and see what it surfaces. Often that one addition reveals more than the whole existing suite did, precisely because it is looking somewhere the suite never looked. Once it is stable, ask the question again. The right number of types is not all of them and it is not one. It is however many it takes to make your real risks visible.

Where this leaves me

"Do you do API testing" is the wrong question, because almost everyone can say yes and almost everyone means the same narrow thing by it. The better question is which failures your current testing cannot see, and which type would make them visible. Answer that honestly and you usually find one or two types worth adding, sitting exactly where your real risk lives. That is the difference between a suite that looks thorough and one that actually is, and it rarely costs as much to close as the gap costs to ignore.