How to test APIs
API testing validates that application programming interfaces work correctly, securely, and performantly. Unlike UI testing, API tests interact directly with the application layer - sending requests and validating responses without a browser or graphical interface.
In 2026, AI tools can draft API test cases from an OpenAPI spec and flag unusual responses, but a person still decides what a correct response looks like. This guide covers the complete workflow: from understanding request-response cycles to leveraging AI for test generation and maintenance.
Types of API testing
API testing covers multiple dimensions. Functional tests verify endpoints work correctly. Security tests probe for vulnerabilities. Performance tests measure throughput under load. Each type requires different tools and approaches.
HTTP methods and their purpose
REST APIs use standard HTTP methods to perform operations. Each method has semantic meaning - understanding these helps you write precise test assertions.
| Method | Operation | Idempotent | Example |
|---|---|---|---|
| GET |
Retrieve resource
Read-only. Should never modify data.
|
Yes | GET /users/123 |
| POST |
Create resource
Creates new record. Returns 201 Created.
|
No | POST /users |
| PUT |
Replace resource
Full replacement. All fields required.
|
Yes | PUT /users/123 |
| PATCH |
Partial update
Update specific fields only.
|
No | PATCH /users/123 |
| DELETE |
Remove resource
Removes record. Returns 204 or 200.
|
Yes | DELETE /users/123 |
API testing workflow
A systematic approach ensures thorough coverage. Start with happy path scenarios, then progressively add negative tests, edge cases, and security validations.
Anatomy of an API request
Every API request consists of an endpoint URL, HTTP method, headers, and optionally a request body. The response includes a status code, headers, and response body.
Response status codes to validate
Negative test cases
Negative testing verifies the API handles bad input gracefully. These tests often catch security vulnerabilities and prevent crashes in production.
| Test Case | Input | Expected Response |
|---|---|---|
| Missing required field | {"email": "test@ex.com"} | 400 + validation error message |
| Invalid data type | {"age": "twenty"} | 400 + type error details |
| Boundary overflow | 1000 character string | 400 + max length error |
| SQL injection | '; DROP TABLE users;-- | 400 or safely escaped |
| XSS attempt | <script>alert(1)</script> | Escaped in response |
| Null value | "name": null | 400 if required field |
API testing tools
Choose tools based on your team's tech stack and whether tests need to run in CI/CD. GUI tools excel at exploration; code-based tools integrate better with automated pipelines.
GraphQL considerations
GraphQL differs from REST in fundamental ways. All requests use POST to a single endpoint. Errors often return 200 status codes with an errors array in the body. Query depth and complexity limits prevent denial-of-service attacks.
Key differences to test
| Aspect | REST | GraphQL |
|---|---|---|
| Endpoints | Multiple routes per resource | Single /graphql endpoint |
| Error status | HTTP status indicates error | Often 200 with errors array |
| Over-fetching | Fixed response shape | Client specifies fields |
| Security tests | Per-endpoint auth | Query depth, field-level auth |
Need API testing for your project?
BetterQA has 50+ engineers who test REST, GraphQL, gRPC and webhook APIs as part of our API testing service. We integrate with your CI/CD pipeline and catch bugs before production.
Talk to our teamThree API checks from our own week
These come from testing betterqa.co and the tools around it in October 2026. Each one is about the same habit: decide what the response must contain before you trust it.
An empty answer that meant nothing.
We read our own task board through an endpoint we had guessed. It came back with no attachments and no comments, and no error. The board's own tool showed both were there. The empty answer was about our request, not about the data.
0 found, 2 presentEvery request said OK. That proved nothing.
When we asked Google to index seven new pages, the transport answered OK each time, which it does whether the request worked or not. The real result is a flag inside the response. We checked that flag for all seven.
7 of 7 flags confirmedThe API said no, and that was correct.
We needed a database change in one of our own products. Its admin API refuses raw writes by design and sends them to a person. The right test result was the refusal, so the change went to a person.
refused, as designedWhere the serious bugs sit.
Of the high and critical bugs our engineers reported in BugBoard on client projects from November 2025 to October 2026, about 1 in 4 was in login, accounts or sessions, and about 1 in 10 in permissions: who may read or change what. Those are API checks first: log in, log out, let a token expire, then repeat the same call as another user. Areas were grouped from bug titles.
1 in 4 in login, accounts or sessionsTested and written by the BetterQA team, reviewed by Tudor Brad, founder. October 2026.
How BetterQA handles this
How BetterQA handles API testing
We test APIs in the order this guide describes: the contract first, then negative and permission cases, then automation that runs in your CI pipeline. Each finding goes into BugBoard, the bug tracker we built, with the request, the response and the steps to reproduce it.
You can add one engineer to your team or hand us a managed QA team. Engagements start from one month, with an NDA and a DPA signed on day one.
Talk to our QA teamTell us what you are testing. We reply within one business day.
Frequently asked questions
Unit tests verify individual functions in isolation, often with mocked dependencies. API tests verify the full request-response cycle through the application layer, testing how components work together. Both are essential - unit tests catch logic bugs early, API tests catch integration issues.
Use Postman for exploration and ad-hoc testing during development. Use code-based tools like REST Assured, pytest, or Supertest for tests that run in CI/CD pipelines. Many teams use both - Postman for discovery, code for automation.
At minimum, test the happy path for each endpoint. Add negative tests for validation. Add auth tests for protected endpoints. A typical CRUD API might have 20-50 tests per resource. Focus on business-critical paths first.
Create test users with known credentials. Generate tokens before test runs. Store tokens as environment variables. Test both authenticated and unauthenticated scenarios. Verify that expired tokens are rejected.
"API testing isn't just about checking endpoints - it's about validating the contracts that hold your entire system together. One broken API can cascade into hundreds of user-facing failures." — Tudor Brad, Founder of BetterQA (15+ years in QA)
Learn more
Built by BetterQA - a software testing company that builds its own tools.
Need help with software testing?
BetterQA provides independent QA services across manual testing, automation, security audits, and performance testing. ISO 27001, 9001, 14001 and 13485 certified.
