What API testing is
An API is a contract between systems. A client sends a request, and the server returns a response. API testing checks whether that contract behaves correctly, securely, and consistently.
For example, a GET user profile request should return the correct profile for the authenticated user. A POST create order request should validate required fields, create the order once, and return useful response data.
What to save
- Situation: The UI looks right while the API response leaks an internal account flag.
- Evidence: The tester checks status, body fields, auth rules, and cleanup.
- Easy miss: The test stops at a green response code and misses the unsafe data.
Why QA testers need API testing
Many defects appear below the UI. The screen may look fine while the response contains missing fields, wrong permissions, weak validation, or confusing errors. API testing helps testers catch those issues earlier.
API testing also supports automation. It is often faster to check data setup, authentication, and business rules through APIs than through a browser.
What to save
- Situation: A search UI shows the first ten users correctly, but the API starts duplicating records after page three when real data volume grows.
- Evidence: The tester checks pagination, totals, ordering, and duplicate behavior beyond the visible first screen.
- Easy miss: The UI smoke check passes while the API defect waits for production data volume.
Requests and responses
A request usually includes a method, URL, headers, optional parameters, optional body, and credentials. A response usually includes a status code, headers, and body.
Better vs weaker evidence
A create order request returns an order ID but leaves the shipping total out of the response body.
Stronger evidence
The tester checks the method, URL, headers, payload, status code, and response fields together.
Thin evidence
The request is marked passed because it returned something, even though the client lacks data it needs.
Status codes
Status codes are not decoration. They tell clients what happened. A 200 can mean success. A 201 can mean created. A 400 can mean the request is invalid. A 401 means the user is not authenticated. A 403 means the user is authenticated but not allowed. A 404 means the resource was not found. Keep the MDN status code reference nearby until the common ones stick.
Testers should check that codes match the behavior. Returning 200 with an error hidden in the body can confuse clients and automation.
Practice lens
An orders endpoint returns 200 even when the payload fails validation.
Useful evidence: The tester confirms the status code, error body, and client behavior agree.
Thin evidence: The response says success while the body hides an error that automation ignores.
Headers, parameters, and payloads
Headers may carry content type, auth tokens, tracing information, or caching rules. Parameters often control filtering, search, pagination, sorting, or options. Payloads carry the data being created or changed.
Good API tests check required fields, optional fields, invalid data, too long values, wrong types, duplicate values, and unexpected fields. A missing required field should fail clearly.
What to save
- Situation: A create-account request accepts a blank email and creates unusable data.
- Evidence: The test covers required, optional, invalid, and overlong values.
- Easy miss: The tester sends only one perfect payload and never sees validation fail.
Authentication and authorization
Authentication proves who the user is. Authorization decides what that user can do. Test both. A request without credentials should usually get a 401. A user trying to access another user’s private record should usually get a 403 or a safe not found response, depending on the product design.
One common mistake is testing only with an admin account. Admin tests can hide permission bugs. The OWASP API Security Top 10 is useful background here because many serious API issues are really authorization and object access issues wearing a boring mask.
What to save
- Situation: A tester logs in as a free-tier user and sends a PATCH request to upgrade their own subscription_tier field directly through the API, bypassing the billing screen entirely. The request succeeds.
- Evidence: The tester checks both that the field can be read with GET and that it can or cannot be modified with PATCH or PUT at the API layer, regardless of what the UI exposes.
- Easy miss: The tester confirms the UI hides the field from free-tier users and considers the access control tested.
Positive and negative API tests
Positive tests confirm expected behavior with valid data. Negative tests confirm the API rejects bad input safely. Try invalid payloads, missing required fields, expired tokens, wrong roles, unknown IDs, too large values, and unsupported methods.
Negative testing is where many API bugs show up. Error messages should be useful enough for legitimate clients, but not so detailed that they reveal sensitive internals.
Practice lens
An order API accepts a negative price and creates broken order data that later appears in reports.
Useful evidence: The tester sends invalid values, missing required fields, wrong types, and confirms the API rejects them safely.
Thin evidence: The tester only sends valid payloads and never checks whether the API protects business rules.
For a ready-to-use work aid, keep the REST API Testing Checklist open while you design endpoint coverage.
Test data and environments
API tests need predictable data. Know whether test data is created fresh, shared, reset, or cleaned up after the run. A test that passes only because yesterday’s data still exists is not trustworthy.
Environment differences matter too. A bug may appear only when a staging service points to an old dependency or a feature flag differs from production.
Better vs weaker evidence
A tester runs a create user, fetch user, delete user sequence and notices the delete returns 200 but the next fetch still returns the user record. Production has eventual consistency the test environment does not.
Stronger evidence
The tester adds a short retry-with-timeout to fetch-after-delete and documents the eventual consistency behavior in the test plan.
Thin evidence
The test passes against the test environment but fails intermittently in staging where the cache layer behaves differently.
Tools QA testers should know
Postman is common for manual API exploration. Browser developer tools help you see requests made by the UI. Command line tools can be useful for quick checks. Automation frameworks can turn important API checks into repeatable tests.
The tool matters less than your coverage thinking. Ask what can fail, what data matters, and which risks deserve repeatable checks.
In practice
A tester uses browser dev tools to find the request, Postman to vary payloads, and version control to save the final automated check.
What helps: Each tool supports a specific testing decision instead of becoming the goal.
What gets missed: The tester stays inside one tool and misses the faster or clearer layer for the risk.
How API testing connects to automation
API tests often become the backbone of fast regression coverage. They can confirm business rules without waiting for a full UI flow. They can also prepare data for UI tests, such as creating a user or order before a browser test starts.
In practice
A team replaces a slow 30-second browser login flow with a 2-second API token request before each UI test, and the suite runtime drops from 40 minutes to 12.
What helps: The API call sets up the authenticated state, and the UI test only exercises the screen behavior that actually needs a browser.
What gets missed: Every UI test re-runs the full browser login, the suite is too slow to run on every push, and the team starts skipping it.
If you want to turn repeated API checks into automated coverage, pair this guide with the automation roadmap.
Common mistakes in API testing
- Checking only 200 responses. A 200 response only says the server returned something. Check the body, permissions, data changes, and error handling so a green status code does not hide a broken contract.
- Testing with admin users and missing permission defects. Admin accounts bypass the rules normal users live under. Test with different roles and record ownership so authorization defects are found before private data leaks.
- Ignoring pagination and rate limit behavior. Pagination and rate limits usually fail after data volume grows. Create enough records to cross page boundaries and confirm the API behaves predictably when request volume is constrained.
- Leaving test data behind and polluting environments. Leftover records make API tests lie. Clean up created users, orders, files, and tokens so the next run proves the product behavior instead of inheriting yesterday’s state.
- Not checking response body fields after create or update requests. Create and update requests need more than a status check. Confirm the response body, stored data, follow-up GET, and downstream UI or workflow that depends on those fields.
Better vs weaker evidence
An API suite looks green until a normal user role exposes that admin-only testing missed authorization and response-field problems.
Stronger evidence
The tester expands coverage to roles, bodies, pagination, data cleanup, and negative cases.
Thin evidence
The team keeps trusting 200 responses while real API behavior remains unchecked.
How to practice API testing
Use a public practice API or a local sample app. Create a small collection with GET profile, POST create order, invalid payload, missing field, 401 unauthorized, 403 forbidden, 404 not found, pagination, and rate limit notes. Write down what each request checks and what risk it covers.
What to save
- Situation: A tester builds a practice collection for profile, order creation, invalid payloads, auth failures, pagination, and cleanup.
- Evidence: The collection includes notes about what each request checks and how test records are removed.
- Easy miss: The practice collection creates records repeatedly until old data makes later checks unreliable.
When you are ready to show this skill on a resume, use the wording patterns in QA Tester Resume Examples.
Prove it with AT*SQA, and stack it into a certification
The skills on this page line up with the three AT*SQA API Testing micro-credentials: Introduction and Testing Planning and Design, REST API gRPC and graphQL, and Environments Tools and Future Proofing. Each exam is $49, includes two open-notes attempts, and is valid for a year.
Prefer guided study first? AT*SQA’s AT*Learn API Testing training (a one-year subscription starting at $39) covers the same ground so you walk into the exams prepared.
Pass all three and AT*SQA awards you the full API Testing certification at no additional cost. That is $147 for three micro-credentials plus the certification, all listed on the Official U.S. List of Certified and Credentialed Software Testers and counted toward your Testing Tiers ranking. On a resume that reads as three specific, verifiable API testing skills instead of "knows Postman."
FAQ
Questions testers ask
Do QA testers need API testing?
Many QA roles benefit from it. API testing helps you check behavior, validation, permissions, and data before relying on the UI.
What should I learn first in API testing?
Start with methods, URLs, status codes, request bodies, response bodies, authentication, authorization, and negative tests.
Is Postman enough?
Postman is a strong starting point. Over time, learn how important API checks can be automated and reviewed in version control.
What is the difference between 401 and 403?
A 401 usually means the user is not authenticated. A 403 usually means the user is known but not allowed to perform the action.
How do I start API testing without a developer background?
Begin with requests, responses, status codes, headers, and JSON payloads. Use a simple API client and write down what each request proves. You do not need to build the API to test whether it validates data, protects access, and returns useful errors.
What API tests should QA run before a release?
Run happy path checks, required field validation, invalid payloads, auth failures, role restrictions, pagination, and cleanup checks for the endpoints touched by the release. Focus on workflows, not isolated endpoints. If checkout changed, test the order API path end to end.
What is the difference between authentication and authorization in API testing?
Authentication confirms who the user is. Authorization controls what that user is allowed to do. A tester should check both, because a valid login does not mean the user should see every record or perform every action.
How do I document API defects clearly?
Include the method, endpoint, headers that matter, request body, response code, response body, environment, and expected behavior. Remove secrets before sharing. A good API bug report lets someone reproduce the issue without rebuilding your request from memory.
Can API testing replace UI testing?
No. API testing gives faster coverage for business rules, data, and permissions, but the UI still needs checks for workflow, usability, rendering, and user-facing error handling. The best coverage uses both layers.