API testing refers to verifying the interfaces that connect software systems, covering protocols beyond REST, including GraphQL, webhooks, and SOAP. Each protocol has distinct rules and trade-offs. Well-designed APIs also reduce the number of calls AI agents must make, which directly lowers token consumption and cost, making API architecture a quality concern, not just a functional one.
Key Takeaways
- APIs optimized for agent use require fewer requests to retrieve the same data, which directly reduces token consumption and lowers operational costs.
- REST is a set of recommendations, not a strict protocol, so teams can and do deviate from its conventions without violating a formal standard.
- MCP works by having the MCP server send a description of its available tools and resources to the LLM at the start of a session, which is how the model learns what actions it can call.
- API-level tests offer greater stability and faster execution than end-to-end browser tests, and the right testing strategy names the layer where each scenario is best covered rather than defaulting to front-end automation.
- Starting API test design from documentation such as a Swagger spec, before the front end exists, removes the wait time at the end of the development cycle and eliminates idle waste.
APIs are the interface most testers still ignore
Testers love the front end. The clicking, the browser, the visible flow. That focus leaves the layer underneath untested, even though the front end is often the least stable place to catch a defect.
The back end gives you predictable, faster feedback. A request goes out, a response comes back, and the result is repeatable. Front-end tests tend to be flaky. When something has to run reliably and quickly, the API layer is where it holds.
Sebastian Malyska calls himself a back-ender by heart. When he has to build a front-end test, he pushes the logic down toward the API wherever he can. Not out of preference alone, but because the back end returns a more predictable output.
The advice is simple. Do not follow the hype about which front-end framework wins. Understand what happens behind the scenes: which protocols move the data, and how systems talk to each other.
The word “API” hides five different things
“We test the API” is too vague to be useful. There are several protocol styles behind that word, and they behave differently. Postman’s report on tens of thousands of companies tracks which ones are actually used.
REST sits at the top and stays there year over year. Webhooks are rising. GraphQL held second place in the 2024 data and has since dropped. The rough top set stays stable: REST, webhooks, GraphQL, and a few more.
REST is a recommendation, not a strict protocol. If someone decides to remove an object with a GET request, that is allowed even if it breaks convention. There was probably a reason. You do not kill the person over it.
SOAP is the opposite case. It is a standardized protocol, used where exactness matters: money, timing, third-party integration. The amount, the time, the format all get pre-validated because the stakes demand it.
GraphQL exists to stop over-fetching. Instead of pulling object A, object B, and object C and matching them on the client side, you send one request that names exactly the data you want. The server returns that, and nothing more.
Knowing these differences is what lets you decide where a test belongs. Without it, “API testing” is a guess.
MCP is the proxy that gives AI agents real data
MCP is the layer that connects language models to real systems so they stop hallucinating. The common analogy, “MCP is like USB for computers,” explains nothing. A closer picture: MCP is the connection to an external device the model would otherwise never reach.
A language model is a clever box, but it stays inside that box. To act on the real world, it needs to interact with real systems. Those systems still speak the old protocols. So something has to sit in the middle, a kind of proxy that talks to the LLM on one side and to classic protocols on the other.
The communication runs on protocols testers already know. JSON-RPC is used by default, carried over different transport layers underneath.
There is no magic in the “automatic detection” of an agent. There is a defined exchange. When the model first talks to an MCP server, the server sends information about itself: which resources it has, which tools it offers. The model remembers a short summary rather than everything at once. It can then ask follow-up requests, for example what data type a given tool expects.
Understanding this handshake is the engineering job. A tester who cannot explain how a system works should not sign off that it works.
Good API design saves tokens and money
An API optimized for agents costs fewer tokens than one designed only for humans. That difference shows up directly in the budget.
Most teams still design APIs the way they always have: a business idea, cut into domains and subdomains, then implemented in code. The result reads logically for a human. Order inside order, then an invoice, a path you can follow in a UI. For an agent, that structure is not efficient.
Very few organizations design their APIs with agent consumption in mind, even though their developers know MCP and their testers already use agentic tools. The optimization opportunity sits at the architectural level, and it starts with a question testers already know how to ask: who are the stakeholders, and what does good quality mean for them?
Nobody asks the AI whether it would rather send five requests or one. But the token count at the end of the month answers that anyway. A well-designed API means fewer round trips, less context to carry, and a smaller bill. Bigger models mean bigger context windows, which makes it tempting to just stuff more data in. Better design does the opposite.
Performance testing gets dismissed as old stuff. Done right, it produces exactly the questions worth asking now: how do we do this with fewer resources? Improving performance is not handing AWS a golden card and asking for more machines. That is the hard way, the engineering way, and it produces defects with real severity and real impact.
A test strategy needs both API and end-to-end
The strongest testing strategy covers both layers, decided feature by feature. Neither full end-to-end coverage nor pure API testing is the answer on its own.
End-to-end automation gets treated as the king. The pull toward “let’s automate everything through the UI” is real, especially for engineers who love the front end. But the numbers make the case. Two thousand API tests can do their work in the same time as three hundred Playwright scenarios. That is not a tournament over who wins, because some things must be checked at the UI and some at the back end. It is a reason to think before defaulting to end-to-end.
The test pyramid is always somewhere in the background. Whether the exact proportions should match a pyramid is another matter. Sit with the feature, look at it honestly, and decide which layer serves each check best. And push developers to do their unit testing.
Self-healing front-end scenarios are improving and may make UI tests more stable against changing websites. Even then, that healing costs extra processing and time. The trade-off does not disappear.
Some behavior is front-end only and has to be tested there. Some is back-end only. Deciding where each check belongs requires understanding both layers, and that decision is best made together with the developers.
If you only know the front end, start here
You will not get bitten by moving toward APIs. Many front-end engineers already work this way without framing it as a new skill.
The pattern is common: end-to-end tests run too slow, so setup and teardown get pushed to the API. Pre-test actions happen through another API. Then the browser opens, the clicks run, the browser closes, and cleanup runs again via API. Advanced engineers rarely still do the whole preparation through the UI.
Your tooling already points the way. Playwright, a front-end tool, ships with an API client built in. There was a time you had to install a separate client and hack it together. The framework authors now treat API access as basic, which tells you where the discipline is heading.
Concrete next steps once you are past REST:
- Learn that REST is not the only protocol. GraphQL, webhooks, and others each solve different problems.
- Use mocking to test edge cases on the front end without depending on a live back end.
- Read API documentation early. A workshop exercise starts with nothing but a Swagger spec: this is your server, this is the only documentation, work out the happy flow.
Testers do not have the privilege of waiting for a finished, good-looking front end. During development you need to read the documentation, understand what the back end does, and start testing against it. When the front end is ready, you run what you already built. Waiting is waste, and waste is not good.
