An API check should verify the promised behaviour, the response data and relevant side effects. A 200 response alone does not prove the request worked correctly.
An API lets software components communicate through defined requests and responses. Testing it directly can reveal problems that are difficult to diagnose through a screen alone, such as incorrect validation, missing permissions or an unexpected stored value.
Use an API you own or are authorised to test. The examples below describe an imaginary local workshop application. They are practice scenarios, not requests to send to a real company's service.
- Read the contract
- Send a useful request
- Verify the state
Read the contract before sending requests
Identify the endpoint, request method, required headers, authentication, input format and promised response. Clarify which fields are required, which values are allowed and what errors should look like. Documentation is a starting point; raise contradictions between the contract and observed behaviour.
For an imaginary POST /bookings endpoint, a valid request might contain a workshop ID and learner ID. Before testing, ask whether the learner comes from the authenticated session, whether the workshop has space and whether duplicate bookings are allowed. These rules define the checks.
Check the response and the resulting state
HTTP status codes communicate categories of outcome. For example, 201 commonly indicates creation, 400 a bad request, 401 missing valid authentication and 403 refusal to authorise. Use the API's documented contract to decide the exact expected code; do not assume every successful operation returns 200.
Inspect the body, headers and side effects as well. If the endpoint returns a booking identifier, can the authorised learner retrieve that booking? Was only one record created? Does a rejected request leave the system unchanged? Verify state through approved test tools rather than guessing from the message.
Further reading: MDN: HTTP response status codes
Build a small request matrix
Change one important condition at a time so a failure is easier to interpret. Start with a valid request, then investigate missing fields, invalid values, repeated requests and permissions. Record both the expected response and the expected effect on stored data.
Do not test authorisation by changing another real person's identifier. Create separate synthetic accounts in an isolated environment and check which resources each is allowed to access. Permission testing needs the same clear scope and evidence as any other check.
| Scenario | Expected behaviour to agree |
|---|---|
| Valid learner and available workshop | Create one booking and return its identifier |
| Missing required workshop | Return a clear validation error; create nothing |
| Workshop is full | Reject according to the contract; do not overbook |
| Repeated identical request | Handle duplicates according to the defined policy |
| Different learner requests the booking | Deny access without exposing private data |
Control data and clean up
Use unique test data and a predictable setup. A workshop that fills up during one test can break later tests for an unrelated reason. Reset the local environment or create isolated records so each case starts from known conditions.
Document cleanup alongside creation. Tests that leave bookings behind can eventually change availability and produce misleading failures. In a shared test environment, coordinate with other testers and avoid deleting records you did not create. Keep API credentials in environment variables or the tool's protected settings, never in a public portfolio.
Automate after the behaviour is clear
Once you understand the contract, automate stable checks for status, important fields and expected state. Prefer specific assertions over copying an entire changing response into an expected fixture. A generated timestamp may vary legitimately while the booking owner must remain correct.
Connect API and interface testing thoughtfully. You can create authorised setup data through an API and verify a user journey in the browser, or use a browser action and inspect its API outcome. Keep the purpose of each layer clear so failures lead to an understandable investigation.
Investigate one local endpoint
- Write the contract for a sample booking request
- Define one valid case and three distinct failure cases
- Check the response and resulting data for each case
- Make the setup and cleanup repeatable before automating
Build these skills with support
Explore live courses with guided practice, projects and space for questions.
Create Your AccountOur practical examples are learning exercises. References are linked beside the relevant sections. Course fees, schedules and access terms are maintained on the course pages. Tell us if something needs correcting.
