What to test at the API level even when the user interface works
The form does not allow an empty name, and another customer’s order does not appear in the list. This does not yet confirm that the server enforces the same rules. The API may be called by a mobile application, a partner integration or a modified request that bypasses the user interface entirely.
The interface mainly shows the successful scenario
The user interface is a good place to verify what should work. It is less suitable for verifying what must not work.
Try submitting an order with a negative quantity through the user interface. The form will probably prevent it. What matters, however, is what the server does when it receives such a request from another client or because of a faulty integration.
We cover these scenarios at the API level, where they can be triggered directly, quickly and repeatably.
Authorisation matrices
Insufficient permission checks are among the more serious defects. An endpoint may verify that a user is logged in without verifying that the record belongs to them. This may not be visible in the interface because the user is not shown a link to another customer’s order.
We therefore construct a matrix: every important endpoint against every role—unauthenticated user, ordinary customer, another customer, sales representative and administrator. We verify not only that the correct role is allowed through, but especially that an incorrect role is denied rather than receiving, for example, an empty response with status 200.
Input validation and boundary values
The server must validate every input independently of checks in the user interface. We test missing required fields, incorrect data types, excessively long strings, invalid date formats, values immediately below and above a limit, zero and negative numbers where only positive values make sense.
If the OpenAPI specification is current and sufficiently precise, tools can derive some boundary and invalid inputs from it. We still supplement generated cases with business rules that the schema itself does not know.
Error states and negative scenarios
An error response is a feature like any other and is tested in the same way. We check whether the API returns the correct status code, whether the error message genuinely explains the problem and whether a failed operation leaves a partial record in the database.
We also verify how the system behaves when something outside it fails: a payment gateway does not respond or the warehouse system is unavailable. In this case, we use a controlled replacement for the external service’s response, known as a mock, to simulate an outage or a slow response. Without it, the only way to test such a scenario would be to wait for it to occur in production.
What you gain
A suite covering permissions, inputs and error states can run with every change in CI. When a test fails, the team receives specific information—for example, that a particular endpoint accepted a negative quantity—instead of a general message that the purchase does not work.
Designing coverage requires knowledge of the interface’s expected behaviour, user roles and important business rules. An up-to-date OpenAPI specification makes the work easier, but missing details can be completed through a discussion with the team and examination of the test environment. Tests can be written in Python with pytest or in Bruno, depending on the team’s technology and experience.
Next step
Start with two lists: critical endpoints and requests the server must reject. If you would like to review priorities and negative scenarios with us, use a no-obligation consultation. More information about the service is available on the API tests page.