300 API Testing Interview Questions & Answers (1970)

API testing is a type of software testing where APIs are tested directly to verify functionality, reliability, performance, and security. Instead of testing only the user interface, testers send requests to API endpoints and validate responses, status codes, headers, payloads, and business rules. API testing is important because APIs connect frontend applications, backend services, mobile apps, and third-party integrations. See API testing.

An API, or Application Programming Interface, is a set of rules that allows different software systems to communicate with each other. In web applications, APIs expose endpoints that clients can call to create, read, update, or delete data. For example, a mobile app may call a login API to authenticate a user and receive a token.

API testing is important because many business rules live in the backend, not just the UI. It helps find defects earlier, validates integrations, improves test coverage, and is usually faster than UI testing. API tests also help verify security, data integrity, error handling, and service reliability.

The main benefits are faster execution, early defect detection, stable automation, better coverage of business logic, easier validation of negative scenarios, and reduced dependency on UI availability. API tests are also useful for regression testing, microservices testing, and CI/CD pipelines.

API testing validates backend services directly by sending requests and checking responses. UI testing validates application behavior through the user interface. API tests are usually faster and less flaky, while UI tests are better for validating complete user journeys and visual behavior.

Common types include functional testing, integration testing, contract testing, security testing, performance testing, load testing, reliability testing, negative testing, schema validation, data validation, and end-to-end API workflow testing.

REST API testing verifies APIs that follow REST architectural principles. It involves testing resources, HTTP methods, status codes, request bodies, response bodies, headers, authentication, authorization, idempotency, pagination, filtering, sorting, and error handling.

SOAP API testing verifies APIs based on the SOAP protocol. SOAP uses XML messages and often relies on WSDL definitions. SOAP APIs are common in enterprise and legacy systems. Testing usually includes XML schema validation, request envelopes, response envelopes, fault handling, and service contracts.

REST is an architectural style that usually uses JSON over HTTP and is lightweight. SOAP is a protocol that uses XML and has strict standards for messaging, security, and contracts. REST is common in modern web and mobile applications, while SOAP is still used in banking, telecom, and enterprise systems.

An endpoint is a specific URL where an API resource or operation is available. For example, /api/users may be an endpoint for retrieving or creating users. Testers validate endpoints by sending requests and checking whether the API returns the expected response.

A resource is an entity exposed by a REST API, such as user, order, product, invoice, or booking. Resources are usually represented using URLs. For example, /users/101 represents a specific user resource.

A request is the message sent by the client to the API server. It usually includes an HTTP method, URL, headers, query parameters, path parameters, request body, and authentication details. The quality of request data directly affects the test coverage.

A response is the message returned by the API server after processing a request. It usually contains a status code, headers, response body, cookies, and sometimes metadata. Testers validate the response to confirm whether the API behaved correctly.

A payload is the actual data sent in a request body or received in a response body. In REST APIs, payloads are commonly JSON. For example, when creating a user, the payload may contain name, email, role, and password fields.

JSON stands for JavaScript Object Notation. It is a lightweight data format commonly used in REST APIs. JSON is easy to read, language-independent, and supports objects, arrays, strings, numbers, booleans, and null values.

XML stands for Extensible Markup Language. It is a structured data format often used in SOAP APIs and legacy integrations. XML uses tags to represent data and supports schema validation through XSD.

API documentation describes how to use an API. It usually includes endpoints, methods, authentication, request parameters, request examples, response examples, error codes, and schemas. Good documentation helps testers design better test cases.

Swagger is a set of tools used to design, document, and test APIs based on the OpenAPI specification. Swagger UI provides interactive API documentation where users can view endpoints, parameters, schemas, and try API requests. See OpenAPI specification.

OpenAPI is a specification for describing REST APIs in a standard machine-readable format. It defines endpoints, methods, parameters, request bodies, responses, security schemes, and schemas. Testers use OpenAPI files for documentation, contract testing, and test generation. See OpenAPI.

Postman is a popular API testing tool used to send requests, validate responses, manage environments, create collections, write test scripts, and run API tests manually or automatically. It is widely used by QA engineers, developers, and SDETs. See Postman.

Rest Assured is a Java library used for API automation testing. It provides a readable syntax for sending HTTP requests and validating responses. It is commonly used with TestNG, JUnit, Maven, Gradle, and CI/CD pipelines. See Rest Assured.

API automation testing means writing automated scripts or collections to test APIs repeatedly. It validates status codes, response bodies, headers, schemas, authentication, business logic, and negative scenarios without manual execution.

A test environment is a controlled setup where APIs are tested. It may include backend services, databases, test data, authentication systems, mock services, and third-party integrations. Common environments include dev, QA, staging, and production-like environments.

API testers should understand HTTP, REST, JSON, status codes, authentication, authorization, databases, Postman, automation tools, test design, negative testing, security basics, and CI/CD. SDET roles also require coding skills in Java, Python, JavaScript, or TypeScript.

Freshers should start with HTTP methods, status codes, headers, query parameters, path parameters, JSON payloads, Postman collections, authentication basics, positive and negative test cases, and basic response assertions. After that, they can learn automation with Rest Assured, Playwright, or Python requests.

HTTP stands for HyperText Transfer Protocol. It is the protocol used for communication between clients and servers on the web. APIs commonly use HTTP to exchange requests and responses using methods like GET, POST, PUT, PATCH, and DELETE. See HTTP.

HTTPS is the secure version of HTTP. It uses TLS encryption to protect data during transmission. API testing should verify that sensitive APIs use HTTPS so credentials, tokens, and personal data are not exposed.

HTTP methods define the action to be performed on a resource. Common methods are GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS. Testers must understand method behavior to validate APIs correctly.

GET is used to retrieve data from a server. It should not modify server state. GET requests are usually idempotent and safe. In testing, validate status code, response body, headers, filters, sorting, pagination, and authorization.

POST is used to create a new resource or trigger an operation. It usually sends data in the request body. POST is not always idempotent, so sending the same request multiple times may create duplicate records unless idempotency is implemented.

PUT is used to replace an entire resource or create it at a known URL. It is generally idempotent, meaning repeating the same request should produce the same final result. Testers should verify full replacement behavior.

PATCH is used to partially update a resource. Unlike PUT, PATCH sends only the fields that need to change. Testers should verify partial updates, unchanged fields, validation errors, and behavior with invalid patch operations.

DELETE is used to remove a resource. It should usually be idempotent, meaning deleting the same resource multiple times should not create unexpected side effects. Testers should verify successful deletion and behavior when deleting a nonexistent resource.

HEAD is similar to GET but returns only response headers without the response body. It is useful for checking resource availability, metadata, caching headers, and content length without downloading the full response.

OPTIONS returns the HTTP methods supported by a resource. It is also used in CORS preflight requests. Testing OPTIONS helps verify allowed methods and cross-origin behavior.

A safe method does not modify server state. GET, HEAD, and OPTIONS are considered safe. However, testers should still verify that GET endpoints do not accidentally create, update, or delete data.

An idempotent method produces the same result even if called multiple times. GET, PUT, DELETE, HEAD, and OPTIONS are generally idempotent. POST is usually not idempotent unless designed with idempotency keys.

Safe means the method should not change server state. Idempotent means repeating the request produces the same final result. For example, DELETE is idempotent but not safe because it changes state by deleting a resource.

HTTP status codes are three-digit numbers returned by the server to indicate request results. They are grouped into 1xx informational, 2xx success, 3xx redirection, 4xx client errors, and 5xx server errors.

200 OK means the request was successful. It is commonly returned for successful GET, PUT, PATCH, or DELETE operations when the response includes a body. Testers should still validate the response body, not only the status code.

201 Created means a resource was successfully created. It is commonly returned after POST requests. The response may include the created resource and a Location header pointing to the new resource.

202 Accepted means the request was accepted for processing but processing is not complete yet. It is common for asynchronous operations. Testers should verify job status endpoints, polling behavior, and final outcome.

204 No Content means the request succeeded but the server returned no response body. It is commonly used for successful DELETE or update operations. Testers should verify that the body is empty.

301 means the resource has permanently moved to a new URL. API clients should update references. Testers validate the Location header and ensure redirection does not break clients.

302 means the resource is temporarily available at another URL. It is commonly used in redirects. API testing should verify whether clients are expected to follow the redirect or handle it manually.

304 means the cached version of the resource is still valid. It is related to caching headers like ETag and If-None-Match. Testers use it to validate caching behavior.

400 means the server could not process the request due to invalid syntax, missing fields, invalid data types, or malformed payload. Testers should verify clear error messages and validation details.

401 means authentication is missing, invalid, or expired. Despite the name, it usually means the user is not authenticated. Testers should verify missing token, invalid token, expired token, and malformed token cases.

403 means the user is authenticated but does not have permission to access the resource. Testers should verify role-based access, ownership rules, and direct endpoint access restrictions.

404 means the requested resource or endpoint does not exist. Testers should validate nonexistent IDs, wrong URLs, deleted resources, and whether the error response is consistent.

405 means the endpoint exists but does not support the HTTP method used. For example, sending DELETE to a read-only endpoint may return 405. Testers should verify allowed methods and response headers.

409 means the request conflicts with the current resource state. It is common for duplicate records, version conflicts, or concurrent updates. Testers should validate conflict scenarios and error messages.

422 means the request is syntactically correct but semantically invalid. It is common for validation errors, such as invalid email format or business rule violations. Testers should validate field-level error responses.

429 means the client has exceeded rate limits. Testers should verify rate limit thresholds, Retry-After headers, error messages, and behavior after the rate limit window resets.

500 means the server encountered an unexpected error. APIs should avoid exposing sensitive stack traces. Testers should report 500 errors with request data, correlation IDs, logs, and steps to reproduce.

Request headers provide metadata about the request. Examples include Content-Type, Authorization, Accept, User-Agent, and correlation IDs. Headers help servers understand request format, authentication, and client expectations.

Response headers provide metadata about the response. Examples include Content-Type, Cache-Control, Set-Cookie, ETag, Location, and security headers. Testers validate headers for correctness, caching, security, and client compatibility.

Content-Type tells the server or client the format of the request or response body. Common values are application/json, application/xml, multipart/form-data, and application/x-www-form-urlencoded. Incorrect Content-Type can cause parsing errors.

The Accept header tells the server which response formats the client can handle. For example, Accept: application/json asks the server to return JSON. Testing Accept headers helps verify content negotiation.

The Authorization header carries credentials or tokens required to access protected APIs. Common formats include Bearer tokens, Basic auth, and API keys. Testers validate valid, missing, expired, and malformed authorization values.

Query parameters are key-value pairs added after a question mark in the URL. Example: /users?page=1&limit=10. They are commonly used for filtering, sorting, searching, and pagination.

Path parameters are dynamic values inside the URL path. Example: /users/{id}. In /users/101, 101 is the path parameter. Testers validate valid IDs, invalid IDs, unauthorized IDs, and nonexistent resources.

Path parameters identify a specific resource, while query parameters modify or filter the request. For example, /users/101 identifies user 101, while /users?role=admin filters users by role.

A request body contains data sent to the API, usually for POST, PUT, or PATCH requests. It can be JSON, XML, form data, or binary data. Testers validate required fields, optional fields, data types, and boundary values.

A response body contains data returned by the API. It may include a resource, list of resources, error object, metadata, pagination details, or status message. Testers validate structure, values, and business rules.

form-data is used to send key-value pairs and files in multipart requests. It is commonly used for file uploads. Testers validate file type, file size, required fields, and upload failure scenarios.

application/x-www-form-urlencoded sends form data as URL-encoded key-value pairs. It is commonly used in older forms and OAuth token requests. Testers verify correct encoding and server parsing.

multipart/form-data is used when a request contains files or mixed content. Each part has its own headers and content. API tests should validate file upload success, invalid formats, large files, and missing file cases.

A cookie stores session or tracking information sent by the server and returned by the client in later requests. API testing may validate Set-Cookie headers, session handling, secure flags, HttpOnly flags, and expiration.

An ETag is a response header used for caching and concurrency control. Clients can send If-None-Match to check whether a resource changed. Testers validate 304 responses and update conflict behavior.

Cache-Control defines how responses should be cached. APIs may use no-cache, no-store, max-age, or private. Testers verify caching behavior especially for sensitive data and frequently accessed resources.

A correlation ID is a unique identifier used to trace a request across services. It is useful in microservices debugging. Testers should capture correlation IDs when reporting API defects.

A request timeout is the maximum time a client waits for a response. API tests should validate that APIs respond within expected time limits and that clients handle timeout errors gracefully.

Response time is the time taken by an API to respond to a request. It is a key performance metric. Testers may set response time assertions for smoke, regression, and performance testing.

Pagination splits large data into smaller pages. Testers validate page number, page size, next/previous links, cursor tokens, total count, sorting stability, and edge cases like empty or last pages.

Sorting controls the order of returned records. Testers verify ascending, descending, default sorting, invalid sort fields, multiple sort fields, and consistency across paginated results.

Filtering returns records that match specific conditions. Testers validate single filters, combined filters, invalid filters, empty results, case sensitivity, and filter behavior with pagination.

Searching allows clients to find resources using keywords or criteria. Testers verify exact match, partial match, case-insensitive search, special characters, no results, and performance for large datasets.

A request payload for creating a user may look like this: ```json { "name": "QA User", "email": "qa@example.com", "role": "tester" } ``` Testers validate required fields, data formats, and whether the created resource matches the payload.

An error response body explains why a request failed. A good error response includes status, error code, message, field-level validation details, and correlation ID. Testers verify that errors are clear and do not expose sensitive information.

Start from API documentation, requirements, business rules, and user workflows. Cover positive cases, negative cases, boundary values, authentication, authorization, schema validation, data validation, error handling, and performance expectations. Good API test design focuses on risk and business impact.

Positive test cases verify expected behavior with valid inputs. For example, creating a user with all required valid fields should return 201 Created and the correct user details. Positive tests confirm the happy path works.

Negative test cases verify how the API behaves with invalid, missing, unauthorized, or unexpected inputs. Examples include missing required fields, invalid token, wrong data type, duplicate records, and invalid IDs. Negative testing improves API robustness.

Boundary value testing checks values at the edges of allowed ranges. For example, if username length must be 3 to 50 characters, test 2, 3, 50, and 51 characters. Boundary tests often reveal validation defects.

Equivalence partitioning divides input data into valid and invalid groups. One or a few representative values from each group are tested. This reduces test count while maintaining meaningful coverage.

Data validation verifies that API responses contain correct values, formats, calculations, and relationships. For example, an order total should equal item price plus tax minus discount. It goes beyond checking status code.

Schema validation verifies the structure of a response, including required fields, data types, nested objects, arrays, and allowed values. It helps catch breaking API changes early. See JSON Schema.

Business rule validation checks whether the API follows product rules. For example, an inactive user should not be able to place an order. These validations are often more important than simple status checks.

End-to-end API workflow testing validates a sequence of API calls representing a business process. For example, create user, login, add product to cart, place order, make payment, and verify order status.

CRUD testing validates Create, Read, Update, and Delete operations for a resource. For example, create a user, retrieve it, update it, verify updates, delete it, and confirm it no longer exists.

Validate required fields, optional fields, duplicate creation, invalid data, response code, response body, database state, headers, and whether the created resource can be retrieved later.

Validate retrieval by valid ID, invalid ID, nonexistent ID, unauthorized access, response schema, response values, filters, sorting, pagination, and performance for large datasets.

Validate full update, partial update, invalid fields, missing required fields, unauthorized update, concurrent update, version conflict, and whether unchanged fields remain correct.

Validate successful deletion, deletion of nonexistent records, repeated delete request, unauthorized delete, soft delete behavior, dependent resource constraints, and whether deleted records are inaccessible.

Soft delete means a resource is marked as deleted but not physically removed from the database. Testers verify that it no longer appears in normal APIs but may still exist for audit or recovery purposes.

Send create requests with duplicate unique fields like email, username, or order number. The API should return an appropriate error such as 409 Conflict or 422 validation error.

Remove required fields from the payload and verify the API returns a clear validation error. Also test null, empty string, whitespace, and wrong data type where applicable.

Send requests with and without optional fields. Verify default values, null handling, omitted fields, and whether optional values are stored and returned correctly.

Send wrong data types, such as string instead of number or boolean instead of object. The API should reject invalid data with a clear validation response, not fail with 500.

Send special characters, emojis, HTML tags, SQL-like strings, and Unicode values in supported text fields. Verify correct storage, encoding, response display, and security handling. CTA after Q100: Ready to practice these API Testing answers in a real interview format? Try AI Mock Interview → /ai-mock-interview Start Free → /login Related: Selenium interview questions.

Send payloads near and above allowed size limits. Verify accepted maximum size, rejection of oversized requests, response time, and error messages. Large payload testing helps prevent performance and memory issues.

Create or query conditions where no records exist. Verify the API returns an empty array, appropriate metadata, and correct status code. Avoid APIs returning null unexpectedly unless documented.

Test first page, last page, page beyond last, page size zero, maximum page size, negative page number, invalid cursor, and sorting consistency. Pagination defects are common in large datasets. See contract testing.

Prioritize critical business flows, high-risk endpoints, authentication, payment or financial APIs, frequently used endpoints, integration points, and APIs with recent changes. Smoke tests should cover core availability and major workflows.

A good API test case has clear purpose, controlled data, expected status code, schema validation, business validation, negative coverage where needed, and cleanup. It should be repeatable, independent, and easy to debug.

Authentication verifies the identity of the client or user calling the API. Common authentication methods include Basic Auth, Bearer tokens, API keys, OAuth 2.0, JWT, and session cookies. Testers validate valid, invalid, missing, and expired credentials.

Authorization verifies whether an authenticated user has permission to perform an action or access a resource. For example, a normal user may view their own profile but should not access admin APIs.

Authentication answers “Who are you?” while authorization answers “What are you allowed to do?” A user can be authenticated but still forbidden from accessing a resource. This commonly results in 403 Forbidden.

Basic Authentication sends username and password encoded in Base64 in the Authorization header. It should only be used over HTTPS because Base64 is not encryption. Testers validate valid credentials, invalid credentials, and missing credentials.

Bearer Token authentication uses a token in the Authorization header. Example: Authorization: Bearer <token>. Anyone with the token can access protected resources, so tokens must be protected and expired properly.

An API key is a unique key used to identify and authorize an application or client. It may be sent in headers, query parameters, or request body. Header-based API keys are generally preferred over query parameters.

OAuth 2.0 is an authorization framework that allows applications to access resources on behalf of users without sharing passwords. It uses access tokens, refresh tokens, scopes, clients, and authorization flows.

JWT stands for JSON Web Token. It is a compact token format containing claims such as user ID, role, issuer, audience, and expiration. JWTs are commonly used for stateless authentication in APIs.

JWT claims are pieces of information inside the token payload. Common claims include sub, iss, aud, exp, iat, and roles. Testers validate claims for correctness and security.

Token expiry defines how long a token is valid. APIs should reject expired tokens with 401 Unauthorized. Testers validate expired token behavior and refresh token flows.

A refresh token is used to obtain a new access token without asking the user to log in again. It usually has a longer lifetime than an access token and must be stored securely. Reference: OWASP API Security Top 10.

Scopes define what access a token provides. For example, read:orders may allow reading orders, while write:orders allows creating or updating orders. Testers validate scope-based access control.

Call protected APIs without credentials. The API should return 401 Unauthorized with a clear error response. It should not expose sensitive data or return 500.

Send malformed, random, tampered, or expired tokens. The API should reject them with 401 Unauthorized. Testers should also verify that tampered JWTs are not accepted. See Newman.

Use a valid token for a user who lacks required permissions. The API should return 403 Forbidden. Also verify that the response does not reveal unauthorized data.

Role-based access control, or RBAC, grants permissions based on roles such as admin, manager, or user. API tests should verify allowed and denied operations for each role.

Object-level authorization ensures users can access only resources they own or are allowed to access. For example, user A should not access user B’s invoice by changing the ID in the URL.

BOLA stands for Broken Object Level Authorization. It occurs when APIs fail to check whether a user is allowed to access a specific object. It is one of the most serious API security risks.

Rate limiting restricts how many requests a client can make in a time window. It protects APIs from abuse and overload. Testers verify limits, 429 responses, Retry-After headers, and recovery after reset.

Input validation ensures user input follows expected format, type, length, and allowed values. It prevents attacks such as SQL injection, script injection, command injection, and malformed data processing.

SQL injection occurs when user input is improperly included in SQL queries. Testers may send SQL-like payloads to verify that the API safely handles input and does not expose database errors.

Cross-site scripting can occur when APIs store or return unsafe HTML or JavaScript that later executes in a browser. API testers should verify proper encoding and sanitization of user-generated content.

Sensitive data exposure happens when APIs return passwords, tokens, personal data, internal IDs, stack traces, or secrets unnecessarily. Testers should inspect responses and logs for exposed sensitive information.

Important headers include Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Cache-Control, and CORS-related headers. API-specific security depends on application context.

CORS stands for Cross-Origin Resource Sharing. It controls whether browsers allow a frontend from one origin to call APIs on another origin. Testers validate allowed origins, methods, headers, and preflight behavior.

CSRF stands for Cross-Site Request Forgery. It tricks an authenticated user into sending unwanted requests. APIs using cookies for authentication should implement CSRF protection for state-changing operations.

A replay attack occurs when an attacker reuses a valid request or token. APIs can prevent it using timestamps, nonces, token expiry, and idempotency keys. Testers validate protection for sensitive operations.

An idempotency key is a unique value sent with a request to prevent duplicate processing. It is common in payment APIs. If the same key is reused, the API should return the original result instead of creating duplicates.

Test authentication, authorization, input validation, sensitive data exposure, rate limiting, CORS, HTTPS enforcement, object-level access, and error handling. For deeper security testing, follow OWASP API Security guidance.

401 means the user is not authenticated or the token is invalid. 403 means the user is authenticated but does not have permission. Correct distinction helps clients respond properly and improves API security clarity.

A Postman collection is a group of API requests organized together. It can include folders, tests, scripts, variables, examples, and documentation. Collections are useful for manual testing, automation, and sharing API workflows.

A Postman environment stores variables such as base URL, token, username, and API key. Environments allow the same collection to run against dev, QA, staging, or production by switching variable values.

Postman variables store reusable values. Types include global, collection, environment, local, and data variables. Variables make requests dynamic and prevent hardcoding repeated values.

Pre-request scripts run before a request is sent. They are used to generate timestamps, signatures, random data, tokens, or dynamic headers. They help prepare requests automatically.

Tests are JavaScript scripts that run after a response is received. They validate status codes, response body, headers, response time, and business rules. Postman tests turn manual requests into automated checks.

Use pm.test with pm.response.to.have.status(). Example: ```js pm.test("Status is 200", function () { pm.response.to.have.status(200); }); ``` This confirms that the API returned the expected status code.

Parse the response using pm.response.json() and assert fields. Example: ```js const body = pm.response.json(); pm.expect(body.email).to.eql("qa@example.com"); ``` This validates actual response data, not just status.

After login, parse the token from the response and store it in an environment variable: ```js const body = pm.response.json(); pm.environment.set("token", body.accessToken); ``` Then use {{token}} in the Authorization header.

Collection runner executes multiple requests in a collection. It supports iterations, test data files, environment selection, and result summaries. It is useful for regression testing and workflow validation.

Newman is Postman’s command-line collection runner. It allows Postman collections to run in CI/CD pipelines. Newman can generate CLI, JSON, HTML, and JUnit-style reports through reporters.

Use the command: ```bash newman run collection.json -e environment.json ``` This runs the collection with the selected environment. Additional options can generate reports and pass data files.

Use collection runner or Newman with CSV or JSON data files. Variables from the data file can be referenced in requests using {{variableName}}. This is useful for testing multiple input combinations.

Global variables are available across all collections and environments in a workspace. They should be used carefully because they can create conflicts. Environment or collection variables are usually safer.

Collection variables are scoped to a specific collection. They are useful for values shared across requests in that collection, such as base paths, default headers, or common IDs.

pm is the Postman JavaScript API object used in scripts. It provides methods for reading responses, setting variables, sending requests, writing tests, and accessing environment data. Related: Playwright interview questions.

Extract data from one response and store it as a variable, then use that variable in later requests. For example, create a user, save userId, then use userId to update or delete the user.

Use pre-request scripts, {{$randomEmail}}, {{$guid}}, timestamps, or custom JavaScript to generate unique data. Dynamic data prevents duplicate conflicts during repeated runs.

Use pm.expect(pm.response.responseTime).to.be.below(1000). This validates that the API responds within the expected threshold. Response time checks are useful in smoke tests but are not a replacement for performance testing.

Use pm.response.headers.get("Header-Name") and assert the value. For example, validate Content-Type is application/json or verify security headers are present.

Postman monitors run collections on a schedule from Postman’s cloud. They help check API availability and correctness over time. They are useful for lightweight monitoring but not a full replacement for enterprise observability.

Postman mock servers return predefined responses for requests. They help frontend teams work before backend APIs are ready and allow testers to simulate different response scenarios.

Swagger mainly documents and describes APIs using OpenAPI, while Postman is used to send requests, automate tests, manage collections, and run workflows. Both can complement each other in API testing.

Postman is excellent for manual and collection-based testing, but complex framework design, advanced coding patterns, large-scale test architecture, and deep CI integration may be better handled with code-based frameworks like Rest Assured or pytest.

Use folders by feature or resource, consistent request names, reusable variables, clear test scripts, environment files, and documentation. Avoid putting unrelated APIs in one large unstructured collection.

A good Postman test validates status code, response schema, important fields, headers, response time, and business rules. It should use variables instead of hardcoding and should be runnable through Newman in CI.

An API automation framework is a structured set of tools, code, utilities, test data, assertions, configuration, and reports used to automate API testing. It improves maintainability, reusability, and CI/CD execution.

Common tools include Rest Assured, Postman/Newman, Playwright request API, SuperTest, pytest with requests, Karate, Cypress API requests, JMeter, K6, and custom HTTP clients. Tool choice depends on language, team skills, and project needs.

Rest Assured is popular in Java projects because it has readable syntax, strong assertion support, JSON/XML parsing, authentication support, and good integration with TestNG, JUnit, Maven, Gradle, and CI/CD.

Example: ```java given() .baseUri("https://api.example.com") .when() .get("/users/1") .then() .statusCode(200) .body("id", equalTo(1)); ``` This validates both status code and response body.

Use body() with contentType(). Example: ```java given() .contentType("application/json") .body("{\"name\":\"QA User\"}") .when() .post("/users") .then() .statusCode(201); ``` In real frameworks, use POJOs or maps instead of raw strings.

given defines request setup, when defines the action, and then defines assertions. This style improves readability and matches behavior-driven testing structure.

Use body with JSON path expressions. Example: .body("data.email", equalTo("qa@example.com")). This allows validation of nested fields, arrays, and values.

Use extract().path() or extract().response(). For example, extract a created user ID and use it in later requests. Extraction supports API workflow testing.

Rest Assured supports Basic Auth, OAuth, Bearer tokens, headers, cookies, and filters. Commonly, testers generate a token using login API and pass it in Authorization header.

Use JSON Schema Validator with Rest Assured. Store schema files in test resources and validate response using matchesJsonSchemaInClasspath. This catches structural API changes.

In Python, the requests library with pytest is commonly used for API testing. It supports simple HTTP calls, fixtures, assertions, parameterization, and integration with CI.

Example: ```python import requests def test_get_user(): response = requests.get("https://api.example.com/users/1") assert response.status_code == 200 assert response.json()["id"] == 1 ``` This is simple and effective for Python-based API automation.

Playwright provides APIRequestContext and the request fixture for API testing. It can test APIs directly and combine API setup with UI tests. It is useful for teams already using Playwright for browser automation.

Example: ```ts import { test, expect } from '@playwright/test'; test('get user', async ({ request }) => { const response = await request.get('/api/users/1'); expect(response.status()).toBe(200); const body = await response.json(); expect(body.id).toBe(1); }); ``` This uses Playwright’s request fixture.

SuperTest is a Node.js library used to test HTTP APIs, especially Express applications. It is useful for backend integration tests and can run without starting a full external server in some setups.

Karate is an API testing framework that uses a readable DSL. It supports REST, SOAP, GraphQL, mocks, assertions, data-driven testing, and performance testing through Gatling integration. It is useful for teams that prefer less Java coding.

A good structure includes tests, clients, endpoints, models, test data, schemas, utilities, config, reports, and environment files. Clear separation helps scale the framework as APIs grow.

An API client class wraps reusable request methods for a resource or service. For example, UserClient may contain createUser, getUser, updateUser, and deleteUser methods. It reduces duplicate request code.

POJOs are Plain Old Java Objects used to represent request and response bodies in Java. They improve type safety, readability, and serialization/deserialization in Rest Assured frameworks.

Serialization converts an object into a format like JSON or XML for sending in a request body. For example, a Java object can be serialized into JSON using Jackson or Gson.

Deserialization converts JSON or XML responses into programming language objects. It helps validate responses using object fields instead of raw JSON path strings.

Reusable assertions are common validation methods used across tests. For example, validateSuccessResponse, validateErrorResponse, or validatePagination. They improve consistency and reduce duplicate code.

Store base URL in configuration files or environment variables. Avoid hardcoding URLs in tests. This allows the same tests to run against dev, QA, staging, or production-like environments.

Generate tokens during setup or use secure CI secrets. Store tokens only in runtime variables, not source code. Refresh tokens when needed and avoid logging sensitive values.

Fixtures provide reusable setup and teardown for tests, such as creating data, generating tokens, initializing clients, or cleaning resources. Pytest and Playwright have built-in fixture concepts.

Use parameterized tests with arrays, JSON files, CSV files, or test data providers. Each data row runs the same test logic with different inputs and expected outputs.

Useful reports include HTML, JUnit XML, Allure, JSON, and CI dashboards. Reports should show endpoint, test name, status, error message, request/response details, and execution time.

Log request method, URL, headers without secrets, payload, status code, response body, correlation ID, and environment. Good failure logs reduce debugging time.

Do not log passwords, access tokens, refresh tokens, API keys, personal data, or sensitive business data. Mask sensitive values before writing logs.

Use clean structure, reusable clients, schema validation, environment configs, secure secret management, meaningful assertions, independent tests, cleanup, CI integration, and clear reporting. Avoid hardcoded data and test dependencies.

JSON schema validation checks whether a JSON response follows an expected structure, data types, required fields, formats, and allowed values. It helps detect breaking changes even when status code is still 200.

Schema validation ensures API consumers receive data in the expected format. It catches missing fields, renamed fields, wrong types, and unexpected structural changes early in testing or CI.

Contract testing verifies that the agreement between API provider and consumer is honored. It checks expected requests and responses without requiring full end-to-end environments. It is useful in microservices.

Consumer-driven contract testing means consumers define their expectations, and providers verify they can satisfy those expectations. Pact is a common tool for this approach.

Pact is a contract testing tool that helps verify interactions between service consumers and providers. It allows teams to detect breaking API changes before deployment.

Contract testing verifies the message agreement between services, often using mocks and provider verification. Integration testing runs real services together to verify actual interaction. Contract tests are faster and more focused.

OpenAPI validation checks whether API requests and responses match the OpenAPI specification. It can validate paths, methods, parameters, schemas, status codes, and security definitions.

OpenAPI helps testers understand endpoints, generate test cases, validate schemas, create mocks, identify missing documentation, and automate contract checks. It improves collaboration between developers and QA.

Backward compatibility means changes do not break existing clients. Adding optional fields is usually backward compatible, while removing fields, renaming fields, or changing data types can break clients.

Breaking changes include removing fields, changing field types, changing required fields, modifying status codes unexpectedly, changing authentication behavior, or removing endpoints. Contract tests help catch them. CTA after Q200: Ready to practice these API Testing answers in a real interview format? Try AI Mock Interview → /ai-mock-interview Start Free → /login Related: SQL interview questions.

API versioning allows changes without breaking existing clients. Common strategies include URL versioning like /v1/users, header versioning, or media type versioning. Testers verify behavior across supported versions.

Test old and new versions for expected behavior, backward compatibility, deprecation warnings, documentation accuracy, and migration paths. Ensure clients using older versions are not unexpectedly broken.

Schema drift happens when actual API responses differ from documented or expected schemas. It can break consumers. Automated schema validation helps detect drift early.

A mock server simulates API responses without using the real backend. It is useful when APIs are not ready, third-party systems are unstable, or rare scenarios are difficult to reproduce.

Service virtualization simulates dependent services with more advanced behavior than simple mocks. It can mimic delays, errors, stateful responses, and complex integration behavior for testing.

Contract-first development means defining the API contract before implementation. Teams agree on OpenAPI or similar specs first, then develop and test against the contract. This improves collaboration and reduces rework.

Schema-first testing means validating APIs against predefined schemas early and consistently. It helps testers detect structural issues before complex business validations.

Define a standard error schema with fields like code, message, details, timestamp, and correlationId. Validate that all error responses follow this structure across endpoints.

Common mistakes include validating only required fields, ignoring nested objects, not validating arrays, allowing additional unexpected fields, and not updating schemas when requirements change.

No. Schema validation checks structure, while functional testing checks behavior and business rules. Both are needed for reliable API quality.

OpenAPI code generation creates clients, server stubs, or models from an OpenAPI spec. Testers may use generated clients for automation, but generated code still needs meaningful assertions.

Verify deprecation headers, documentation, backward compatibility, warning messages, and planned removal behavior. Deprecated APIs should still work as promised until their retirement date.

API governance defines standards for design, security, documentation, versioning, error handling, and lifecycle management. Testing helps enforce governance by validating APIs against agreed standards.

Check that fields contain only allowed values defined by schema or requirements. Also test invalid enum values in requests and verify proper validation errors.

Use JSON path, object mapping, or schema validation to check nested fields, arrays, and relationships. Validate both structure and important business values.

API tests depend heavily on data. Good test data ensures repeatability, independence, and accurate validation. Poor data management causes flaky tests, false failures, and environment pollution.

Test data setup creates required records before a test runs. It can be done through APIs, database scripts, fixtures, seed data, or mocks. API-based setup is often the safest and fastest approach.

Cleanup removes or resets test-created data after execution. It prevents duplicate conflicts and environment pollution. Cleanup should be idempotent and safe even if a test fails.

Seed data is predefined stable data loaded into an environment. Examples include roles, permissions, countries, categories, and test users. Tests can rely on seed data if it is controlled and versioned.

Dynamic test data is generated during test execution, such as unique emails, IDs, names, or timestamps. It prevents conflicts when tests run repeatedly or in parallel.

Use UUIDs, timestamps, random suffixes, or worker-specific identifiers. For example, qa_user_20260619_001@example.com. Unique data helps avoid duplicate record failures. Reference: GraphQL documentation.

Use isolated users, unique records, worker-specific data, and cleanup by test identifiers. Avoid shared mutable data because parallel tests can update or delete each other’s records.

Use database validation when response alone is not enough to verify persistence or backend state. However, avoid overusing database checks because they can couple tests tightly to implementation details.

Direct database testing may bypass business logic, create fragile tests, expose schema changes, and require sensitive access. Prefer API-based validation unless database verification is necessary.

Database seeding loads predefined data before tests. It helps create known conditions for API tests. Seed data should be stable, documented, and resettable.

Create dependencies through setup APIs or fixtures. For example, create a customer before creating an order. Avoid relying on manually created data that may change or disappear.

Mocking replaces a real dependency with a controlled fake response. It helps test unavailable services, rare error states, third-party failures, and frontend development before backend readiness.

Stubbing provides predefined responses for specific requests. It is simpler than full service virtualization and useful for predictable scenarios. Stubs usually do not contain complex business logic.

A stub returns predefined data, while a mock can also verify interactions and expectations. In practice, the terms are often used loosely, but mocks are more behavior-focused.

Mock APIs when a dependency is unstable, unavailable, costly, slow, difficult to control, or belongs to a third party. Do not mock everything because real integration coverage is still needed.

WireMock is a tool for mocking HTTP APIs. It can return predefined responses, match requests, simulate delays, and verify interactions. It is commonly used in integration and contract-style testing.

Use mocks for most regression tests and sandbox environments for limited integration tests. Validate request format, authentication, retry behavior, error handling, and mapping of third-party responses.

Test valid files, invalid file types, empty files, large files, missing file field, metadata, virus scan behavior, and response validation. Also verify storage or retrieval if applicable.

Validate status code, Content-Type, Content-Disposition, file name, file size, file content, authorization, and behavior for missing files. For large files, verify streaming and timeout handling.

Use test email inboxes, mock email providers, mail capture tools, or API access to email logs in lower environments. Avoid relying on real external email delivery for automated regression.

Use test provider sandboxes, mocks, static OTPs, or internal message retrieval APIs. Real SMS delivery is slow, costly, and unreliable for automated tests.

Use sandbox payment gateways, test cards, idempotency keys, webhook validation, failure scenarios, refunds, partial captures, and duplicate request handling. Never use real payment credentials in test automation.

Control time using test configuration, mock clocks if supported, or use predictable test windows. Validate timezone handling, expiry, scheduled jobs, and date boundaries carefully.

Identify shared data, missing cleanup, environment changes, duplicate records, and parallel conflicts. Fix by using unique data, isolated users, better setup APIs, and cleanup routines.

Anti-patterns include hardcoded shared users, no cleanup, dependency on manual data, production data usage, tests requiring specific execution order, and direct database changes without rollback.

GraphQL is a query language for APIs where clients request exactly the data they need. Unlike REST, GraphQL usually uses a single endpoint and supports queries, mutations, subscriptions, schemas, and resolvers.

REST testing focuses on multiple endpoints, methods, and status codes. GraphQL testing focuses on queries, mutations, variables, schema validation, field-level authorization, errors array, and response data structure.

A GraphQL query is used to fetch data. Testers validate requested fields, nested objects, variables, response data, missing fields, and authorization rules.

A mutation modifies data, such as creating or updating a record. Testers validate input variables, response fields, database changes, authorization, validation errors, and rollback behavior if needed.

Variables are dynamic values passed to GraphQL queries or mutations. They make operations reusable and safer than string concatenation. Testers validate required variables, optional variables, invalid types, and boundary values.

The schema defines available types, fields, queries, mutations, and relationships. Testers use the schema to design tests and detect breaking changes.

Introspection allows clients to query the GraphQL schema. It is useful for tooling and documentation. In production, teams may restrict introspection for security reasons.

Validate field-level and operation-level access. A user may be allowed to access a query but not certain sensitive fields. Testers should check both data and errors.

Common scenarios include missing required variables, invalid types, unauthorized fields, resolver failures, partial responses, query depth limit errors, and validation errors.

GraphQL can return both data and errors in the same response. Testers should validate not only HTTP status but also the errors array and whether partial data is acceptable. Related: QA Practice Hub.

A microservice is a small independently deployable service responsible for a specific business capability. APIs connect microservices. Testing microservices requires contract testing, integration testing, mocks, and observability.

Challenges include many dependencies, asynchronous communication, distributed data, versioning, contract changes, environment instability, observability, and debugging across services.

Use a mix of unit tests, contract tests, service tests, integration tests, end-to-end tests, and monitoring. Avoid relying only on full end-to-end tests because they are slower and more brittle.

Asynchronous processing means the API accepts a request and processes it later. It may return 202 Accepted and provide a job ID or status endpoint. Testers validate polling, callbacks, queues, and final state.

Validate initial 202 response, job ID, status endpoint, state transitions, timeout behavior, failure states, and final result. Use polling with sensible timeouts instead of hard waits.

A webhook is an HTTP callback sent by one system to another when an event occurs. For example, a payment provider may send a payment_success webhook to an application.

Test event payload, signature verification, retries, duplicate events, ordering, failure handling, idempotency, and security. Use mock receivers or local tunneling tools in lower environments.

Event-driven architecture uses events to communicate changes between systems. Testing requires validating event publishing, consuming, ordering, retries, dead-letter queues, and eventual consistency.

Eventual consistency means data may not be immediately consistent across systems but becomes consistent after some time. Tests should use polling and verify final state rather than expecting instant updates.

Publish messages, verify consumption, validate payload, check retries, dead-letter handling, ordering, duplicate handling, and idempotency. Tools depend on Kafka, RabbitMQ, SQS, or other queue systems.

Kafka testing validates producers, consumers, topics, message schemas, offsets, ordering, retries, and failure handling. It often requires test containers, embedded Kafka, or controlled test topics.

gRPC is a high-performance RPC framework that uses Protocol Buffers. It is common in microservices. Testing gRPC involves validating service methods, request/response messages, status codes, deadlines, and metadata.

gRPC uses protobuf messages and RPC methods instead of JSON over REST endpoints. Testers validate proto contracts, method responses, deadlines, metadata, streaming, and gRPC-specific status codes.

API gateways route requests to backend services and handle authentication, rate limiting, logging, caching, routing, and transformation. Testers validate gateway rules, security, routing, and error handling.

Service discovery allows services to find and communicate with each other dynamically. Testing service discovery directly is usually infrastructure-focused, but API testers may see failures caused by routing or unavailable services.

API performance testing measures response time, throughput, latency, error rate, and resource usage under expected and peak load. It helps ensure APIs meet performance requirements.

Load testing checks API behavior under expected user or request volume. It validates whether the API can handle normal traffic with acceptable response times and error rates.

Stress testing pushes APIs beyond expected limits to find breaking points. It helps understand system capacity, failure behavior, and recovery ability.

Spike testing suddenly increases API traffic to observe how the system handles rapid load changes. It is useful for systems affected by campaigns, flash sales, or sudden user activity.

Soak testing runs APIs under sustained load for a long time. It helps detect memory leaks, resource exhaustion, connection leaks, and performance degradation over time.

Latency is the delay before a response starts or completes. Low latency is important for user experience and system responsiveness. Testers measure latency across endpoints and network conditions.

Throughput is the number of requests processed in a given time, such as requests per second. Performance tests validate whether throughput meets expected business needs.

Error rate is the percentage of failed requests during testing or monitoring. High error rates may indicate server instability, timeout issues, rate limits, or dependency failures.

Common tools include JMeter, K6, Gatling, Locust, Postman performance features, and cloud-based load testing tools. Tool choice depends on scripting needs, reporting, protocol support, and team skills.

Reliability testing validates whether APIs behave consistently over time and under different conditions. It includes retry behavior, timeout handling, dependency failures, rate limits, and graceful degradation.

API monitoring continuously checks availability, response time, status codes, and correctness of production or staging APIs. Monitoring helps detect incidents quickly after deployment.

A synthetic check is a scheduled test that calls an API like a client would. It validates availability and basic behavior from different locations or environments.

Run API tests after deployment to test environments, publish reports, fail builds on critical failures, manage secrets securely, and use smoke/regression tags. API tests are excellent for fast pipeline feedback.

Smoke API testing is a small set of critical tests that verify core API availability and major business flows. It runs quickly after builds or deployments.

Regression API testing verifies that existing API behavior still works after changes. It includes positive, negative, schema, security, and workflow tests for important endpoints.

Analyze logs, environment availability, data conflicts, dependency failures, timeouts, and parallel issues. Add retries only for known transient issues, and fix root causes instead of hiding failures.

Retry logic automatically repeats failed requests for transient errors like 502, 503, 504, or network timeouts. Tests should verify retry limits, backoff strategy, and no duplicate side effects.

Circuit breaker prevents repeated calls to a failing service. It opens after failures and recovers later. API tests may validate fallback responses and recovery behavior in resilience testing.

Important metrics include response time, latency, throughput, error rate, availability, CPU, memory, database time, dependency latency, and rate-limit usage. These metrics help evaluate API health.

Include endpoint, request method, payload, environment, response times, percentiles, error rate, load level, timestamps, correlation IDs, and comparison with expected SLA. Clear evidence helps developers identify bottlenecks.

Test valid login, invalid password, nonexistent user, locked account, inactive account, missing fields, SQL injection strings, rate limiting, token generation, token expiry, refresh token behavior, and whether sensitive data is excluded from responses.

Test successful payment, declined card, insufficient funds, invalid card, duplicate request, idempotency key, timeout, refund, partial refund, webhook events, currency validation, and security of payment data.

Test valid order, missing items, invalid product ID, out-of-stock product, price mismatch, discount calculation, tax calculation, unauthorized user, duplicate order, and retrieval of created order.

Test valid registration, duplicate email, invalid email, weak password, missing required fields, maximum length fields, email verification, default role assignment, and whether password is hashed and never returned.

Test exact match, partial match, case sensitivity, special characters, empty search, no results, pagination, sorting, filters, response time, and relevance of returned results.

Validate page size limits, first page, last page, invalid page, cursor behavior, stable sorting, duplicate prevention, total count accuracy, and performance for large datasets. Also test pagination with filters and sorting together.

Create users with different roles and test allowed and denied operations. Verify both endpoint access and object-level access. Also test direct URL manipulation and unauthorized resource IDs.

Compare old and new versions, validate existing fields and status codes, run contract tests, check deprecation rules, and verify old clients can still consume responses without changes.

Mock the third-party service for regression tests and use sandbox testing for limited integration coverage. Validate success, timeout, retry, error mapping, authentication failure, and fallback behavior.

Reproduce with exact request, check payload, headers, authentication, environment, logs, correlation ID, database state, and dependency status. Report the issue with full request/response details while masking secrets.

Run tests in parallel, split smoke and regression suites, use API setup instead of UI setup, avoid unnecessary waits, reuse authentication setup carefully, reduce duplicate tests, and run only impacted tests in CI.

Use reusable API clients, environment configs, secure secrets, schema validation, test data builders, contract checks, reporting, logging, CI integration, tagging, parallel execution, and clear coding standards. Keep tests independent and maintainable.

Automate stable, high-value, repeatable, business-critical API scenarios. Prioritize authentication, payments, orders, data validation, integrations, and regression-prone endpoints. Avoid automating unstable or one-time exploratory scenarios too early.

A senior QA should explain the test pyramid, risk-based coverage, API/UI balance, contract testing, security checks, performance testing, CI integration, test data strategy, and observability. The focus should be business confidence, not only tool usage.

Start with HTTP, REST, JSON, status codes, and Postman. Then learn authentication, authorization, test case design, schema validation, and negative testing. After that, learn automation using Rest Assured, Playwright, or Python requests, followed by contract testing, CI/CD, security, and performance basics. After Q300, add this FAQ section: Related: AI Mock Interview.