How to test an API (2026)
Quick Answer
To test an API, start by understanding its specification, authentication method and expected responses, then send controlled requests and check whether the status codes, headers, body and behaviour match the documentation. Good API testing also covers invalid input, authentication failures, edge cases, rate limits and repeatability, not just whether one request returns data.
Overview
API testing is the process of checking that an application programming interface behaves correctly, reliably and safely when another system sends requests to it. In practice, that means confirming the endpoint, method, headers, authentication, request body and parameters are correct, then verifying the response content, status code, timing and error handling. A sound test approach starts with the API contract, such as an OpenAPI definition or official documentation, because that tells you what the API claims to accept and return. From there, you can run manual tests with a client such as Postman, Insomnia or curl, and then automate the important checks so they run repeatedly in development and deployment pipelines. The most useful tests are not only the “happy path” where valid data works, but also the failure paths: missing fields, invalid formats, expired tokens, unsupported methods and excessive request rates. Logging request and response details matters because API issues are often caused by small mismatches in headers, data types or authentication. If you test in a structured order, you can quickly isolate whether the problem is in your request, the API contract, the server implementation or the environment.
Who this is for
Developers, QA testers, technical product teams and anyone integrating with a web API such as REST, JSON-based HTTP APIs or documented service endpoints.
What you’ll need
- Access to the API documentation or specification, ideally OpenAPI or official reference docs
- A valid base URL for the correct environment, such as development, staging or production
- Authentication details if required, such as an API key, bearer token or OAuth credentials
- An API client or command-line tool, for example Postman, Insomnia or curl
- Sample request data and expected response examples
- A way to inspect logs or error messages if you control the API
Before you start
Confirm which environment you are allowed to test, whether test data is available, and whether the API enforces authentication, IP restrictions, rate limits or data retention rules. Make sure you know whether your tests are read-only or will create, update or delete real records.
Step-by-step
- 1
Read the API contract and choose a test case
Review the official documentation for the endpoint you want to test. Note the HTTP method, path, required headers, authentication method, required and optional parameters, request body format, expected status codes and example responses. Start with one simple, valid test case before moving to edge cases.
Why: Most API test failures come from sending the wrong method, path, header or payload. Starting from the contract stops you testing the wrong thing.
- 2
Prepare the environment and authentication
Set the correct base URL and gather any credentials needed for the chosen environment. If the API uses bearer tokens or OAuth, obtain a fresh token using the documented flow. If it uses API keys, put them in the correct header or parameter as required by the documentation.
Why: Authentication and environment mistakes can look like API defects when they are really setup problems.
- 3
Send a valid request and capture the full response
Use your API client or curl to send a minimal valid request. Record the request method, URL, headers, parameters and body. Then inspect the full response, including status code, headers and body. Check that the response format matches the documentation and that required fields are present with sensible values.
Why: A successful baseline proves the endpoint is reachable and gives you a known-good example to compare against later tests.
- 4
Verify behaviour, not just status codes
Check that the API did what it was meant to do. For a create request, confirm the record was actually created. For an update, fetch the resource again and verify the change. For a delete, confirm the resource is no longer available or is marked deleted according to the API design.
Why: An API can return a success code while failing to perform the intended action fully or correctly.
- 5
Test invalid input and error handling
Send requests with missing required fields, invalid data types, unsupported values, bad authentication, wrong methods and malformed JSON if relevant. Confirm the API rejects bad requests cleanly and returns documented error structures without exposing sensitive internal details.
Why: Robust APIs must fail safely and predictably, because real integrations will eventually send bad or incomplete data.
- 6
Check edge cases and non-functional behaviour
Test empty responses, large payloads if permitted, duplicate submissions, pagination, filtering, sorting, idempotency where applicable and rate-limit behaviour if documented. If response time matters, compare performance across repeated requests under normal conditions using your team's accepted thresholds rather than guessing what is acceptable.
Why: Many production issues appear only in less common conditions, not in a single straightforward request.
- 7
Automate repeatable tests
Turn the important manual checks into automated tests using your chosen framework or API client test scripts. Include assertions for status codes, schema or field presence, authentication failures and key business rules. Run them in continuous integration against the correct non-production environment where possible.
Why: Automation catches regressions quickly and ensures the same checks are run consistently after code or configuration changes.
- 8
Log findings and keep test data tidy
Document the requests you sent, the environment, the expected result and the actual result. Clean up any test records if the API modifies data, or use isolated test accounts and datasets designed for this purpose.
Why: Good records make issues reproducible and stop test activity polluting real data or confusing later investigations.
Why this works
API testing works because it compares actual observable behaviour at the interface boundary against a documented contract and expected business outcome. By validating both successful and failing requests, you confirm interoperability, correctness and resilience from a consumer's point of view.
Common mistakes to avoid
- Testing only successful requests and ignoring invalid input, expired credentials and permission errors
- Using the wrong environment or stale credentials and assuming the API itself is broken
- Checking only the response code without confirming the underlying action really happened
- Hard-coding tokens, IDs or environment-specific values into automated tests
- Running destructive tests against production data without approval or isolation
- Ignoring headers such as content type, authorisation or pagination links
Troubleshooting
You get 401 or 403 responses
Check whether the token or API key is valid, unexpired and sent in the correct place. Also confirm the account has permission for that endpoint and environment.
You get 404 for an endpoint you believe exists
Verify the base URL, API version, path spelling, trailing slash behaviour and HTTP method. Make sure you are calling the correct environment.
The API returns 400 Bad Request
Compare your request body, query parameters and headers against the documentation. Look for missing required fields, wrong data types, invalid JSON or unsupported values.
A request succeeds but the data is wrong or incomplete
Check field names, serialisation format, locale-sensitive values, pagination and whether the endpoint returns a summary rather than the full resource. Follow up with a GET request to confirm persisted state.
Automated tests pass locally but fail in CI
Review environment variables, secret injection, network access, test data setup and ordering dependencies. Ensure tests do not rely on local state or manually created records.
Compare your options
Manual testing with Postman or Insomnia
Best for: Exploring an API, debugging requests and learning the endpoint behaviour
Pros: Easy to inspect requests and responses, low setup effort, good for quick experiments
Cons: Harder to scale, repeat and enforce consistently without automation
Command-line testing with curl
Best for: Quick checks, scripting and reproducing issues exactly
Pros: Works well in terminals and scripts, easy to share as a plain request example
Cons: Less convenient for complex workflows and visual inspection
Automated tests in a development framework
Best for: Regression testing and continuous integration
Pros: Repeatable, version-controlled and suitable for pipelines
Cons: Needs more setup and maintenance than ad hoc manual testing
| Option | Best for | Pros | Cons |
|---|---|---|---|
| Manual testing with Postman or Insomnia | Exploring an API, debugging requests and learning the endpoint behaviour | Easy to inspect requests and responses, low setup effort, good for quick experiments | Harder to scale, repeat and enforce consistently without automation |
| Command-line testing with curl | Quick checks, scripting and reproducing issues exactly | Works well in terminals and scripts, easy to share as a plain request example | Less convenient for complex workflows and visual inspection |
| Automated tests in a development framework | Regression testing and continuous integration | Repeatable, version-controlled and suitable for pipelines | Needs more setup and maintenance than ad hoc manual testing |
Alternatives
- Contract testing to verify that a client and API agree on request and response structure
- Schema validation against an OpenAPI definition
- Mock server testing when the real API is unavailable or costly to call
- Browser-based end-to-end testing when the API is exercised only through an application interface
Pro tips
- Start with one small valid request, then vary one thing at a time so you can isolate failures quickly
- Save known-good requests as named collections or scripts for reuse
- Use test accounts and synthetic data wherever possible
- Record the exact request and response when reporting an API bug
- If the API supports idempotency keys, use them for retry-related tests
Safety notes
- Do not expose real API keys, tokens or customer data in screenshots, shared collections, source control or chat messages
- Be careful with destructive endpoints such as delete, bulk update and financial actions
- Avoid load or rate-limit testing on production without explicit approval
- Mask or minimise personal data when testing systems that handle sensitive information
Legal & regulatory notes
Testing may be restricted by contracts, acceptable use terms, security policies and data protection rules. Only test APIs you are authorised to use, and handle personal or confidential data in line with your organisation's compliance requirements and applicable law.
What this guide does not cover: This guide covers practical API testing at a general level. It does not provide tool-specific walkthroughs, formal performance test design, penetration testing procedures or endpoint-specific assertions for a particular vendor API.
Cost considerations
API testing can create usage costs if the provider charges per request, per data volume or for premium environments. Automated suites that run frequently can increase consumption, so use test environments, mocks or smaller datasets where suitable.
Frequently asked questions
Do I need coding skills to test an API?+
Not always. You can do useful manual testing with tools like Postman or Insomnia using the documentation. Coding becomes more important when you automate tests or need to generate complex data and workflows.
What is the first thing I should check if an API test fails?+
Check the request basics first: URL, HTTP method, headers, authentication and payload shape. These cause many failures and are quicker to verify than deeper server-side issues.
Should I test only the response body?+
No. You should also check status codes, headers, side effects, error structure and whether the API actually changed or returned the underlying data you expected.
Can I test an API without access to the real backend?+
Yes. You can use mock servers, example responses or contract tests to validate client behaviour, though that does not replace testing against the real implementation.
How much of the API should I automate?+
Automate stable, high-value checks first: authentication, core endpoints, key business flows and common error cases. Leave exploratory testing for manual investigation where it still adds value.
Sources & references
Guidance on this page is traced to documented sources. Last checked 24 September 2026.
- MDN Web Docs: HTTP request methods · industry
Supports correct use of HTTP methods and general request semantics when testing API endpoints.
- OpenAPI Initiative · industry
Supports using an API specification or contract as the basis for request, response and schema validation.
The core testing method changes slowly, but tools, authentication flows and provider-specific API conventions change regularly.