>_ API Testing Checklist

Short answer

An API Testing Checklist is a list of checks for API endpoints that helps make sure the backend correctly accepts requests, validates input data, returns the right status codes and response body, respects authentication and authorization, does not expose unnecessary data, handles errors, remains stable under expected usage, and does not break existing clients after changes.

API testing is especially important for web apps, mobile apps, SaaS products, e-commerce platforms, marketplaces, internal tools, integrations, payment flows, public APIs, partner APIs, and any product where a frontend, mobile app, or external system communicates with the backend through an API.

A good API testing checklist does not stop at checking whether an endpoint returns 200 OK. It should verify the full contract between client and server: request format, required fields, optional fields, validation, permissions, response schema, data correctness, errors, pagination, filtering, sorting, rate limits, idempotency, versioning, security, logs, and backward compatibility.

The main idea is: API testing checks whether the backend can be used safely and predictably through its API contract.

This guide can also be used as a REST API testing checklist, backend testing checklist, or API regression checklist for web, mobile, SaaS, and integration-heavy products.

API Testing vs UI Testing

API testing and UI testing are connected, but they test different layers of the product.

UI testing checks what the user sees and does in the interface:

• pages;
• forms;
• buttons;
• navigation;
• layout;
• mobile view;
• user-facing errors;
• end-to-end flows.

API testing checks how the backend handles requests:

• endpoints;
• HTTP methods;
• request parameters;
• request body;
• authentication;
• authorization;
• validation;
• response status codes;
• response schema;
• database changes;
• error handling;
• rate limiting;
• API security;
• integrations;
• backward compatibility.

In simple terms: UI testing answers "can the user complete an action in the interface?", while API testing answers "does the backend process this action correctly at the data and contract level?"

When to use an API Testing Checklist

Use this checklist whenever an API, backend logic, or the data accepted and returned by an API changes.

For example:

• a new endpoint is added;
• an existing endpoint changes;
• request body changes;
• response body changes;
• status codes change;
• new validation logic is added;
• authentication changes;
• roles or permissions change;
• business logic changes;
• database schema changes;
• pagination, filtering, or sorting changes;
• a new integration is added;
• public API contract changes;
• mobile app API changes;
• partner integration API changes;
• webhooks are added;
• rate limit changes;
• API versioning is added;
• backend refactoring is performed;
• there was an API-related bug or production incident.

For a small change, a short API smoke test may be enough. For a new API, public API, partner integration, or major backend change, it is better to go through the full API testing checklist.

Quick API Testing Checklist

If you need a minimal API smoke test, check that:

• the endpoint is available;
• the correct HTTP method works;
• the wrong HTTP method is handled correctly;
• a request with valid data returns the expected status code;
• response body matches the expected schema;
• required fields are actually required;
• invalid data returns a clear error;
• authentication works;
• unauthorized request is rejected;
• a user without permissions cannot access restricted data or actions;
• response does not contain unnecessary sensitive data;
• data is created, updated, or deleted correctly;
• pagination, filtering, or sorting works, if available;
• error response has a stable format;
• rate limit works, if expected;
• API does not return 500 for normal invalid requests;
• logs help identify the problem;
• API regression smoke test passes after changes.

This is not full API QA. It is a minimal check that helps quickly confirm whether an endpoint works at a basic level.

Track this checklist in qa::checklist

You can use this guide as a manual API testing checklist, or track it in qa::checklist as a QA project. Split checks by endpoint, method, authentication, authorization, validation, schema, security, webhooks, and production smoke, then export the completed result to CSV.

Full API Testing Checklist

1. Define the API scope

Before starting API testing, it is important to understand what exactly needs to be checked: one endpoint, a group of endpoints, a public API, internal API, mobile API, webhook API, or a full backend flow.

Check that:

• endpoints included in scope are known;
• endpoints outside scope are known;
• HTTP methods that need testing are defined;
• user roles that use the API are known;
• clients that use the API are known: web, mobile, partner, internal tool;
• supported request parameters are known;
• supported request bodies are known;
• expected response formats are known;
• business rules are known;
• expected database changes are known;
• affected external integrations are known;
• critical scenarios are defined;
• the person responsible for the pass / fail decision is known.

If the scope is not defined in advance, API testing can become chaotic: the team may check the happy path but miss permissions, validation, error format, pagination, rate limiting, or backward compatibility.

2. Prepare the environment, tools, and test data

API testing should be repeatable. To make that possible, prepare the environment, test users, tokens, data, and tools in advance.

Check that:

• test or staging environment is available;
• the latest backend version has been deployed;
• base URL is correct;
• API documentation is available;
• test users are created;
• users with different roles are available;
• access tokens or API keys are available;
• test data is prepared;
• data for positive scenarios is available;
• data for negative scenarios is available;
• data in different statuses is available;
• access to the database or admin panel is available, if needed;
• access to logs or monitoring is available;
• test integrations are available if the API calls external services;
• a request tool is available: Postman, Insomnia, curl, automated tests, or another API client.

API testing should not depend on random data. If test data is unstable, test results will be unstable too.

3. Check API documentation and contract

API documentation is the contract between the backend and API consumers. If documentation does not match actual API behavior, integrations can break.

Check that:

• endpoint is described in the documentation;
• HTTP method is correct;
• request parameters are described;
• request body is described;
• required fields are marked;
• optional fields are described;
• authentication requirements are clear;
• permissions are described, if important;
• response status codes are listed;
• response schema is described;
• error response format is described;
• examples are up to date;
• deprecated fields are marked;
• versioning is described, if used;
• documentation does not contain outdated endpoints;
• documentation matches actual API behavior.

For public APIs, partner APIs, and mobile APIs, the contract is especially important. Even a small change in a response field can break an external client.

4. Check endpoint availability and routing

Start with the basics: the endpoint should be available at the correct URL and respond as expected.

Check that:

• endpoint is available at the correct path;
• base URL is correct;
• path parameters are handled;
• query parameters are accepted;
• endpoint does not return 404 if it should exist;
• endpoint returns 404 for a non-existing resource;
• endpoint does not point to an old route;
• endpoint does not point to staging or the wrong environment;
• trailing slash is handled as expected;
• case sensitivity works according to product rules;
• deprecated endpoint behaves as expected;
• disabled endpoint is unavailable if it should be closed.

If routing is configured incorrectly, deeper endpoint testing does not make much sense.

5. Check HTTP methods and semantics

Each endpoint should accept only the HTTP methods it actually supports.

Check that:

• GET is used for retrieving data;
• POST is used for creating an action or resource;
• PUT or PATCH is used for updates;
• DELETE is used for deletion;
• unsupported method returns a correct error;
• method not allowed does not return 500;
• GET request does not change data;
• DELETE actually deletes or changes status according to product logic;
• PATCH updates only provided fields, if expected;
• PUT replaces the resource according to API contract, if used;
• OPTIONS works if needed for CORS.

It is important to check not only the correct method but also incorrect methods. The API should not perform a dangerous action because of the wrong method.

6. Check authentication

Authentication answers the question: who is making the request?

Check that:

• request with a valid token works;
• request without a token is rejected;
• request with an invalid token is rejected;
• request with an expired token is rejected;
• request with a malformed token is rejected;
• request with a revoked token is rejected;
• API key works, if used;
• incorrect API key is rejected;
• refresh token flow works, if included in scope;
• token expiration is handled correctly;
• authentication error returns the correct status code;
• authentication error does not expose unnecessary information;
• sensitive endpoints always require authentication.

If the API accepts unauthenticated requests where authentication is required, that can be a critical security bug.

7. Check authorization and permissions

Authorization answers the question: what is this user or client allowed to do?

Check that:

• user can access only their own data;
• user cannot access someone else's data;
• regular user cannot perform admin actions;
• admin can perform admin actions;
• manager sees only allowed resources;
• guest cannot access private endpoints;
• direct request to another user's resource ID is rejected;
• role-based permissions work;
• organization-level permissions work if there are teams or workspaces;
• read permission does not grant write access;
• write permission does not grant admin access;
• deleted or suspended user cannot use the API;
• permission error returns the correct status code;
• response does not expose the existence of a private resource, if this matters.

Authorization bugs are often invisible in the UI but easy to trigger through direct API requests. That is why permissions should be tested separately.

8. Check request parameters

Request parameters should be accepted, validated, and interpreted predictably.

Check that:

• required query parameters are required;
• optional query parameters can be omitted;
• path parameters are handled correctly;
• invalid parameter value returns a clear error;
• unsupported parameter does not break the endpoint;
• unknown parameter is ignored or returns an error according to contract;
• numeric parameter accepts only valid numbers;
• boolean parameter is handled correctly;
• enum parameter accepts only allowed values;
• date parameter accepts the correct format;
• timezone is handled if important;
• special characters are handled safely;
• too-long parameters do not break the API;
• empty string is handled correctly;
• null is handled correctly if the request format allows it.

Parameters are especially important for list endpoints, search, filters, reports, exports, and analytics APIs.

9. Check request body validation

The API should accept a valid request body and reject an invalid request body in a clear and stable way.

Check that:

• valid request body is accepted;
• required fields are actually required;
• optional fields can be omitted;
• missing required field returns a clear error;
• incorrect type returns a validation error;
• extra fields are handled according to contract;
• null values are handled correctly;
• empty strings are handled correctly;
• arrays are validated;
• nested objects are validated;
• enum values are validated;
• min and max values are checked;
• length limits work;
• invalid date format is rejected;
• malformed JSON returns a correct error;
• request body that is too large is handled correctly;
• backend validation does not conflict with API documentation.

Validation errors should not turn into 500. If the user sends incorrect data, the API should return a predictable client error.

10. Check response status codes

Status codes help API consumers understand the result of a request without parsing the entire response body.

Check that the API correctly returns:

• 200 for successful GET or update, if this is the convention;
• 201 for created resource, if used;
• 204 for successful action without response body, if used;
• 400 for invalid request;
• 401 for unauthenticated request;
• 403 for authenticated user without permissions;
• 404 for non-existing resource;
• 405 for unsupported method;
• 409 for conflict, if there is a state conflict;
• 422 for validation errors, if this convention is used;
• 429 for rate limit;
• 500 only for real server errors.

The key point is consistency. The same type of error should not sometimes return 400, sometimes 500, and sometimes 200 with an error inside the body.

11. Check response body and schema

Response body should match the API contract and remain stable for clients.

Check that:

• response body has the expected structure;
• field names are correct;
• data types are correct;
• required response fields are present;
• optional fields are handled predictably;
• null values are expected and documented;
• arrays are returned in the correct format;
• nested objects are correct;
• IDs are returned correctly;
• dates have the correct format;
• timezone is expected;
• numeric values are accurate;
• enum values match the contract;
• response does not contain unnecessary internal fields;
• response does not contain sensitive data;
• schema does not break existing clients.

Response schema is especially important for mobile apps, public APIs, and partner integrations where clients may depend on specific fields.

12. Check data correctness in the response

The API may return the correct schema but the wrong data. That is why you should check not only format but also content.

Check that:

• response contains data for the correct user;
• response contains the correct resource;
• IDs match the request;
• created data is visible after creation;
• updated data is actually updated;
• deleted data is no longer returned if expected;
• calculated fields are correct;
• status is correct;
• timestamps are correct;
• totals, counters, or metrics are correct;
• related objects match the main resource;
• list endpoint returns the expected set of data;
• response data matches the database or admin panel, if needed.

For API testing, "the response arrived" is not enough. You need to make sure the data in the response is actually correct.

13. Check error handling and error response format

Errors should be clear, stable, and safe. API consumers should understand what went wrong and how to fix the request.

Check that:

• error response has a consistent structure;
• error code is returned, if used;
• error message is clear;
• validation errors point to specific fields;
• multiple validation errors are returned correctly;
• authentication error is clear;
• permission error is clear;
• not found error is clear;
• conflict error is clear;
• server error does not expose stack trace;
• raw database error is not returned to the client;
• raw third-party error is not exposed unnecessarily;
• error status code matches the error type;
• API does not return 200 with an error body for a real error unless this is a documented convention.

Good error handling matters not only for QA but also for developers, support teams, and external API consumers.

14. Check CRUD operations

If the API works with resources, check the full lifecycle: create, read, update, delete.

Check that:

• resource is created;
• created resource can be retrieved by ID;
• created resource appears in list endpoint;
• resource is updated;
• updated fields change;
• unchanged fields stay the same;
• partial update works, if supported;
• invalid update is rejected;
• resource is deleted or archived according to logic;
• deleted resource is no longer available, if expected;
• delete does not incorrectly remove related data;
• repeated delete is handled correctly;
• user without permissions cannot create, update, or delete resource.

CRUD testing is especially important for admin panels, dashboards, internal tools, e-commerce catalogs, SaaS settings, and user-generated content.

15. Check business rules and state transitions

An API often needs to enforce business logic, not just save data.

Check that:

• resource can move only to an allowed status;
• forbidden status transition is rejected;
• order cannot be canceled after a certain status, if expected;
• subscription cannot be activated without payment, if this is a product rule;
• user cannot be invited twice if this is forbidden;
• plan limits are enforced;
• trial logic works;
• approval flow works;
• workflow steps happen in the correct order;
• repeated action does not create an invalid state;
• API does not allow bypassing business rules that are restricted in the UI.

It is very important to test business rules directly through the API. Sometimes the UI blocks an action, but a direct API request can still perform it.

16. Check pagination

List endpoints should handle pagination correctly, especially when there is a lot of data.

Check that:

• default pagination works;
• limit parameter works;
• offset or page parameter works;
• cursor pagination works, if used;
• next cursor is returned correctly;
• previous cursor is returned, if needed;
• total count is correct, if returned;
• limit cannot be too large;
• invalid page parameter returns a clear error;
• empty page is returned correctly;
• item order does not change unexpectedly between pages;
• pagination works with filters;
• pagination works with sorting;
• response schema is the same for different pages.

Pagination bugs often appear with real data when the list becomes large. That is why pagination should not be tested only with two objects.

17. Check filtering, sorting, and search

Filtering, sorting, and search should return accurate and predictable results.

Check that:

• filter by one field works;
• multiple filters work together;
• invalid filter value is handled correctly;
• unknown filter does not break the endpoint;
• sorting by one field works;
• sorting direction asc / desc works;
• invalid sort field returns an error or is ignored according to contract;
• search by exact value works;
• search by partial value works, if supported;
• search is case-insensitive, if expected;
• empty search results are returned correctly;
• filters do not return resources the user cannot access;
• search does not expose private data.

For list APIs, it is important to test combinations: filter + sort, search + pagination, multiple filters + permissions.

18. Check headers, content type, and CORS

Headers often affect how APIs are used by frontends, mobile apps, browsers, and external clients.

Check that:

• API accepts the correct Content-Type;
• API rejects unsupported Content-Type, if expected;
• response returns the correct Content-Type;
• Authorization header is handled;
• request ID or correlation ID is passed, if used;
• caching headers are configured correctly, if important;
• CORS is configured for allowed origins;
• forbidden origins do not get access, if expected;
• preflight OPTIONS request works if the API is used by a browser client;
• security headers are present if they are part of the product standard;
• response headers do not expose unnecessary information.

CORS and headers often break frontend integration even when the endpoint itself works in an API client.

19. Check idempotency, retries, and duplicate requests

The API should correctly handle repeated requests, especially for actions that create data, charge money, send emails, or trigger integrations.

Check that:

• repeated request does not create a duplicate resource without reason;
• idempotency key works, if used;
• duplicate POST is handled safely if this is a critical action;
• retry after timeout does not create an incorrect state;
• repeated callback does not create duplicate action;
• double submit does not create duplicate records;
• repeated delete is handled correctly;
• repeated update does not break data;
• user gets a consistent response on repeated request;
• logs make it possible to distinguish a retry from a new action.

Idempotency is especially important for payments, checkout, order creation, bookings, emails, imports, and webhooks.

20. Check concurrency and race conditions

Some API bugs appear only when several requests happen almost at the same time.

Check that:

• two simultaneous updates do not create incorrect data;
• two simultaneous creates do not create duplicates if duplicates are forbidden;
• two users cannot book the same slot if it must be unique;
• stock does not go into a negative value;
• limit is not exceeded under simultaneous requests;
• optimistic locking works, if used;
• last-write-wins is used only where it is acceptable;
• conflict returns the correct status code;
• data remains consistent after concurrent actions;
• logs make it possible to understand the conflict.

Concurrency is especially important for booking, ticketing, inventory, payments, subscriptions, quotas, and collaborative tools.

21. Check rate limiting and throttling

Rate limiting protects the API from abuse, accidental overload, and too frequent requests.

Check that:

• rate limit is applied to the correct endpoints;
• rate limit depends on user, IP, API key, or organization if expected;
• after exceeding the limit, API returns the correct status code;
• error message is clear;
• Retry-After header is returned, if used;
• limit reset works;
• authenticated and unauthenticated limits differ, if expected;
• admin or internal clients have the correct limits;
• rate limit does not block normal usage;
• rate limit does not expose unnecessary information.

Rate limiting is especially important for public APIs, login endpoints, search APIs, exports, expensive calculations, and external integrations.

22. Check API security basics

API testing does not replace a security audit, but basic security checks should be part of QA.

Check that:

• sensitive endpoints require authentication;
• authorization is checked on the backend;
• user cannot access someone else's data through direct ID;
• input validation protects against obvious injection attempts;
• API does not return stack traces;
• API does not return internal errors;
• API does not expose secret keys;
• API does not expose tokens;
• API does not return password hashes;
• API does not return unnecessary personal data;
• admin endpoints are not available to regular users;
• debug mode is not enabled in production;
• insecure HTTP is not used for sensitive API;
• CORS is not too open if that would be dangerous;
• file upload endpoints check type and size if uploads exist.

The main rule: do not rely on the UI as protection. All permissions and validation must be checked on the backend.

23. Check sensitive data and privacy

APIs often return data that users should not see: private fields, internal notes, tokens, emails, addresses, billing data, admin flags.

Check that:

• response does not contain password or password hash;
• response does not contain secret keys;
• response does not contain access tokens unless necessary;
• response does not contain private admin fields;
• user does not see someone else's personal data;
• user does not see someone else's emails, addresses, or billing data;
• public endpoint does not return private fields;
• logs do not contain sensitive request body;
• error responses do not expose sensitive data;
• exported data is limited by permissions;
• deleted or anonymized data is not returned through API;
• privacy rules are respected for all roles.

Sensitive data leaks through API can be invisible in the UI but critical for security and trust.

24. Check file upload and download APIs, if applicable

If the API supports uploading or downloading files, these endpoints should be tested separately.

Check upload:

• valid file is uploaded;
• unsupported file type is rejected;
• file that is too large is rejected;
• empty file is handled correctly;
• file name with special characters works safely;
• duplicate file name is handled;
• upload progress or async status works, if available;
• file is linked to the correct user or resource;
• user cannot upload a file to someone else's resource;
• malware scanning or moderation starts, if expected.

Check download:

• authorized user can download the file;
• unauthorized user cannot download the file;
• direct URL does not open a private file without permissions;
• correct content type is returned;
• file name is correct;
• expired link is unavailable if signed URLs are used;
• deleted file is unavailable;
• download does not expose storage path or internal metadata.

File APIs are often connected to security, storage, permissions, and performance, so they should not be tested only with the happy path.

25. Check webhooks and callbacks, if applicable

Webhooks are APIs in the opposite direction: the product sends events to an external system or receives events from an external service.

Check outgoing webhooks:

• webhook is sent after the correct event;
• payload schema is correct;
• event type is correct;
• resource ID is correct;
• timestamp is correct;
• signature is added, if used;
• retry works on failure;
• duplicate delivery does not break the receiver, if this is considered;
• webhook logs are available;
• webhook does not send unnecessary sensitive data.

Check incoming callbacks:

• valid callback is accepted;
• invalid signature is rejected;
• duplicate callback does not create duplicate action;
• delayed callback updates status correctly;
• out-of-order callback does not break state;
• callback failure is logged;
• API returns the expected status code to the external service.

Webhooks are especially important for payments, shipping, CRM, email, subscriptions, marketplace integrations, and automation flows.

26. Check API versioning and backward compatibility

If the API is used by a mobile app, external partners, or public clients, backward compatibility is critical.

Check that:

• current API version works;
• old supported version still works;
• new version does not break old clients;
• deprecated fields are not removed without warning;
• new fields are added in a backward-compatible way;
• required fields did not change unexpectedly;
• response schema does not break existing clients;
• version is specified in URL, header, or another mechanism according to product convention;
• unsupported version returns a clear error;
• documentation for versions is up to date;
• migration path is clear if API changes.

Backward compatibility is especially important for mobile apps because users may stay on older app versions for a long time.

27. Check caching behavior

Caching can make APIs faster, but it can return outdated or someone else's data if configured incorrectly.

Check that:

• cache is used only where it is safe;
• private user data is not cached publicly;
• updated data appears after update;
• deleted data is not returned from cache;
• cache invalidation works;
• cache headers match expected behavior;
• ETag or If-None-Match works, if used;
• stale data does not break a critical flow;
• cache does not mix data from different users;
• CDN does not return a private API response to another user.

Caching bugs can be painful: the API appears to work, but returns old or incorrect data.

28. Check performance and response time

The API should respond fast enough for expected usage. A slow API can break the UI, mobile app, or integration.

Check that:

• key endpoints respond within acceptable time;
• list endpoints work with a large amount of data;
• filters and search are not too slow;
• pagination does not degrade on large offsets or datasets;
• create / update actions do not hang;
• external integration delay is handled;
• timeout returns a clear error;
• response size is not too large;
• N+1 queries or overly heavy responses do not create problems;
• API performance is acceptable on staging and production-like data;
• logs or monitoring show slow endpoints.

API performance testing does not always mean load testing. Sometimes it is enough to check that key endpoints do not become slow on realistic data.

29. Check load, limits, and large data

Some APIs work on small data but break when volume grows.

Check that:

• endpoint works with a large list;
• large request body is handled according to limits;
• large response does not break the client;
• export endpoint works with large data;
• import endpoint works with large files, if available;
• bulk create or bulk update works, if supported;
• timeout limits are clear;
• API returns an error for a request that is too large;
• queue or async processing works, if used;
• user sees status for long-running operation;
• system does not fail under realistic peak usage.

Large data scenarios are especially important for reports, analytics, exports, imports, search, and admin APIs.

30. Check GraphQL API, if applicable

If the product uses GraphQL, some checks are different from REST API testing.

Check that:

• schema is up to date;
• queries work;
• mutations work;
• required arguments are required;
• optional arguments work;
• invalid query returns a clear error;
• unauthorized field is unavailable;
• user cannot request someone else's data;
• nested fields do not expose sensitive data;
• query depth limit works, if used;
• query complexity limit works, if used;
• pagination works;
• errors have a consistent format;
• deprecated fields are marked;
• schema changes are backward-compatible;
• introspection is configured according to the security policy.

For GraphQL, field-level permissions are especially important. Even if the main object is protected, a nested field can accidentally expose unnecessary data.

31. Check API automation and regression

API testing is a good fit for automation because endpoints can be checked quickly and consistently.

Good candidates for automation:

• authentication checks;
• core endpoints;
• CRUD operations;
• validation rules;
• permissions;
• response schema;
• pagination;
• filtering;
• business-critical workflows;
• API smoke test;
• API regression test;
• contract tests;
• negative scenarios;
• health checks.

Check that:

• automated tests run in CI/CD;
• tests use stable test data;
• tests do not depend on execution order;
• tests clean up data after execution, if needed;
• flaky tests are fixed;
• critical API changes block release;
• schema changes are checked automatically;
• failures provide clear diagnostics.

Manual API testing is useful for new endpoints, exploratory checks, and complex scenarios. But stable API regression checks are usually better automated.

32. Check logs, monitoring, and observability

When an API breaks, the team should be able to quickly understand what happened.

Check that:

• errors are logged;
• request ID or correlation ID is used, if expected;
• logs do not contain sensitive data;
• validation errors can be found in logs, if needed;
• server errors appear in monitoring;
• slow endpoints are visible in monitoring;
• failed integrations are logged;
• rate limit events are visible, if important;
• webhook failures are visible;
• alerts are configured for critical endpoints;
• support or engineering team can find a request by ID, user, or timestamp.

Observability does not replace API testing, but without it API bugs are harder to investigate and fix.

33. Run production API smoke after release

After releasing API changes, run a short production check. Some issues appear only in production because of environment variables, API keys, database, permissions, caching, routing, or integrations.

Check that:

• production API is available;
• health check passes, if available;
• critical endpoint responds;
• authentication works;
• core API flow works;
• permissions work on critical endpoints;
• response schema is not broken;
• important integration endpoint works;
• logs do not show a sudden increase in errors;
• monitoring does not show a latency spike;
• error rate has not increased;
• mobile or frontend client is not receiving widespread API errors;
• feature flags are configured correctly;
• API documentation or changelog has been updated, if needed.

Production smoke should be short and safe. Its goal is to make sure real clients can continue using the API after release.

Common mistakes

1. Checking only 200 OK

Status 200 alone does not prove much. The API may return 200 with incorrect data, wrong schema, unnecessary sensitive fields, or an error inside the response body.

2. Not checking negative scenarios

A valid request is important, but invalid requests are just as important. The API should correctly handle missing fields, invalid types, wrong permissions, expired token, unsupported method, and malformed JSON.

3. Confusing authentication and authorization

Authentication checks who is making the request. Authorization checks what this user is allowed to do. If you only check login or token validity, you may miss serious permission bugs.

4. Relying on the UI as protection

The UI may hide a button, but the API endpoint may still accept a direct request. All business rules, validation, and permissions should be enforced on the backend.

5. Not checking response schema

Even a small change in field name, type, or nested structure can break the frontend, mobile app, or external integration.

6. Ignoring error format

If errors are returned in a different format each time, API consumers cannot handle problems reliably. Error response should be consistent.

7. Not testing pagination and filters together

Pagination may work separately, and filters may work separately, but the combination can break. For list endpoints, combined scenarios should be tested.

8. Not checking idempotency

Repeated requests, retries, duplicate callbacks, and double submit can create duplicate resources or invalid states. For critical actions, idempotency is required.

9. Not checking backward compatibility

An API may work for the new frontend version but break an older mobile app or partner integration. Public and mobile APIs should be checked for compatibility.

10. Not looking at logs and monitoring

An API may "work" during a test while creating background errors, slow queries, or failed integrations. Logs and monitoring help reveal issues that are not always visible in the response.

FAQ

What is an API Testing Checklist?

An API Testing Checklist is a list of checks for API endpoints. It helps make sure that the API accepts correct requests, validates input data, returns correct status codes and response body, respects authentication and authorization, handles errors, does not expose sensitive data, and remains stable after changes.

What should be checked in API testing?

At minimum, check:

• endpoint availability;
• HTTP methods;
• authentication;
• authorization;
• request parameters;
• request body validation;
• response status codes;
• response schema;
• data correctness;
• error handling;
• CRUD operations;
• pagination, filtering, and sorting;
• sensitive data;
• rate limits;
• idempotency;
• performance basics;
• logs and monitoring;
• API regression smoke after release.

How is API testing different from UI testing?

UI testing checks what the user can do through the interface. API testing checks how the backend accepts a request, processes data, applies permissions, returns a response, and saves the result.

The UI may look correct while the API returns incorrect data or allows forbidden actions through a direct request.

What is a REST API Testing Checklist?

A REST API Testing Checklist is a set of checks for REST endpoints. It usually includes:

• endpoint URL;
• HTTP method;
• path parameters;
• query parameters;
• request body;
• status codes;
• response schema;
• authentication;
• authorization;
• validation;
• errors;
• pagination;
• filtering;
• sorting;
• rate limiting;
• idempotency;
• versioning.

The main goal is to make sure the REST API behaves according to its contract and HTTP semantics.

How do you test an API endpoint?

An API endpoint should be tested in several scenarios:

• valid request;
• missing required fields;
• invalid data types;
• invalid parameter values;
• unauthenticated request;
• unauthorized request;
• non-existing resource;
• unsupported method;
• malformed request;
• large request;
• duplicate request;
• expected business rule violation.

After that, check status code, response body, database effect, logs, and related system behavior.

Which status codes should be checked in API testing?

Common status codes to check include:

• 200 for successful request;
• 201 for created resource;
• 204 for success without body;
• 400 for invalid request;
• 401 for unauthenticated request;
• 403 for forbidden action;
• 404 for resource not found;
• 405 for method not allowed;
• 409 for conflict;
• 422 for validation error, if used;
• 429 for rate limit;
• 500 only for real server error.

It is important that status codes are consistent across similar endpoints.

How do you test API authorization?

Authorization should be tested with different users and roles.

Check that:

• user can access their own data;
• user cannot access someone else's data;
• regular user cannot perform admin action;
• admin can perform admin action;
• guest cannot see private resources;
• direct request to another user's resource ID is rejected;
• organization-level permissions work;
• read-only user cannot modify data.

Authorization testing is especially important to do directly through the API, not only through the UI.

What should be checked in API error handling?

In API error handling, check:

• correct status code;
• consistent error response format;
• clear error message;
• field-level validation errors;
• no stack trace;
• no raw database errors;
• no sensitive data;
• correct behavior for malformed JSON;
• correct behavior for missing fields;
• correct behavior for unauthorized and forbidden requests.

A good error response helps client applications, developers, and support teams understand the problem faster.

Should API testing be automated?

Yes. API testing is a strong fit for automation because endpoints can be checked quickly, consistently, and without UI.

Good candidates for automation include:

• API smoke tests;
• authentication;
• permissions;
• CRUD operations;
• validation;
• response schema;
• critical business flows;
• regression tests;
• contract tests;
• health checks.

Manual API testing is still useful for new endpoints, complex edge cases, and exploratory testing.

How do you know an API is ready for release?

An API can be considered ready for release when:

• critical endpoints work;
• request validation is correct;
• response status codes are consistent;
• response schema matches the contract;
• data is returned correctly;
• authentication works;
• authorization works;
• errors are handled predictably;
• sensitive data is not exposed;
• pagination, filtering, and sorting work;
• API does not break existing clients;
• automated API regression tests pass;
• logs and monitoring do not show critical issues;
• production API smoke has passed after release.

Create an API testing checklist

Use this API testing checklist as a starting point for your next REST API, backend release, mobile API, webhook flow, or partner integration. In qa::checklist, you can organize checks by endpoint, method, auth, validation, schema, permissions, security, and production readiness, then export the completed checklist to CSV.