API Testing
API testing is checking an application programming interface directly, without the user interface, by sending requests and asserting on what comes back: the status code, the response body and its schema, the error format and whether access was correctly allowed or denied. It matters because integration and authorization defects often sit at this layer.
Key takeaways
- Tests the contract between systems, not the screens
- Runs faster and breaks less often than UI tests over the same logic
- The OpenAPI description is the expected result, so tests and docs stay aligned
- Authorization checks belong in API tests, not only in security reviews
- A good suite asserts status, schema, errors, idempotency and rate limits
What API Testing means
An API test acts as a client. It sends a request to an endpoint, then checks every part of the response against what the API promises. No browser or mobile app is involved, so the test reaches business logic and data rules that a screen may hide or never trigger.
API testing matters because so much of modern software is an API. Mobile apps, partner integrations, webhooks and internal services all call endpoints. A defect there reaches every client at once, and an authorization gap is open to anyone who can send a request, whatever the UI allows.
Agnotic Technologies writes API tests as part of the APIs and integrations it builds for clients. How API tests fit with unit, UI and end-to-end tests and into CI gates is covered on our test automation services page, and API penetration testing is part of our security testing work.
How is API testing different from UI testing?
A UI test checks what a person sees; an API test checks what the system returns. API tests run faster, do not depend on page layout and can send cases the UI would block, such as malformed input or a missing token.
UI tests still matter for the journeys people take. Many teams put most checks at the API layer and keep a smaller set of UI tests for the key flows.
How does an OpenAPI description become the test oracle?
An OpenAPI description lists each endpoint, its parameters, the response codes it can return and the schema of each response. A test can load it and validate every response against the matching schema, so a field that changes type or disappears fails the build.
That also keeps the documentation honest. If the API changes and the description does not, the tests fail until one of them is corrected.
What does an object-level authorization test look like?
Take a patient portal API where each user may read only their own appointments. A test signs in as user A, requests user B's appointment by its ID and expects 403 or 404, never 200.
That one test covers the risk OWASP ranks first for APIs, broken object level authorization, and it runs on every commit instead of once a year in a penetration test.
What should a single API test assert?
Not every test needs every line, but a suite should cover each one somewhere. The right column names the rule each check comes from.
| Check | What to assert | Where the rule comes from |
|---|---|---|
| Status code | The exact code for the case, such as 201 for a create and 404 for a missing record, not just any 2xx | RFC 9110 status code semantics |
| Response schema | The body matches the schema for that status in the OpenAPI description, including required fields and types | The API's OpenAPI description |
| Object-level authorization | A user cannot read or change another user's object by changing an ID in the request | OWASP API Security Top 10, API1:2023 |
| Error format | Errors return a consistent, machine-readable body with a type, title and detail | RFC 9457 Problem Details for HTTP APIs |
| Idempotency | Repeating a PUT or DELETE leaves the same end state as sending it once | RFC 9110 idempotent methods |
| Rate limiting | Too many requests return 429, ideally with a Retry-After header | RFC 6585, status 429 |
Facts and primary sources
The OpenAPI Specification defines a standard, programming language-agnostic interface description for HTTP APIs that lets people and computers understand a service without access to its source code.
Source: OpenAPI SpecificationThe OWASP API Security Top 10 2023 lists Broken Object Level Authorization as API1, the first risk on the list.
Source: OWASP API Security Top 10 2023RFC 9110 defines HTTP semantics and states that, of the request methods it defines, PUT, DELETE and the safe methods are idempotent.
Source: IETF RFC 9110, HTTP SemanticsRFC 9457 defines a problem detail format for carrying machine-readable details of errors in HTTP responses, so APIs do not need to invent their own error formats.
Source: IETF RFC 9457, Problem Details for HTTP APIs
Explore this on Agnotic
Where API Testing shows up in how we build.