API Testing

Top 35 API Testing Interview Questions and Answers

HelpMeTest

HelpMeTest

— 13 min read
Top 35 API Testing Interview Questions and Answers

API testing has become one of the most critical skills in modern software quality engineering. As applications shift toward microservices and mobile-first architectures, APIs carry the lion's share of business logic — and bugs found at the API level are far cheaper to fix than those discovered through the UI. This guide covers 35 of the most common API testing interview questions, with answers designed to show real depth.

1. What is API testing and why is it important?

API testing validates the application programming interfaces of a system — verifying that they function correctly, securely, and reliably. Unlike UI testing, API tests communicate directly with the application's business logic layer, bypassing the frontend entirely. This makes them faster, more stable, and better at pinpointing the exact location of a failure. API tests are also crucial for microservices architectures where services communicate with each other — a broken API contract can cascade into multiple downstream failures that are hard to debug from the UI.

2. What is the difference between REST and SOAP APIs?

REST (Representational State Transfer) uses standard HTTP methods, is stateless, typically returns JSON or XML, and is lightweight and flexible. It's the dominant architecture for web APIs today. SOAP (Simple Object Access Protocol) is a protocol with a formal specification, uses XML exclusively, supports ACID transactions and WS-Security standards, and has strict contracts defined by WSDL documents. SOAP is more common in enterprise and financial systems where formal contracts and built-in error handling are required. For most modern web and mobile applications, REST is the practical choice.

3. What HTTP methods are used in REST APIs and what do they do?

  • GET — retrieves a resource, no request body, idempotent and safe (no side effects)
  • POST — creates a new resource, returns 201 Created with Location header; not idempotent
  • PUT — replaces an entire resource, idempotent (same result if called multiple times)
  • PATCH — partially updates a resource, idempotent in practice though not strictly required to be
  • DELETE — removes a resource, idempotent
  • HEAD — like GET but returns only headers, useful for checking if a resource exists
  • OPTIONS — describes the communication options for a resource, used in CORS preflight requests

Idempotency matters for retry logic — it's safe to retry idempotent requests after a network failure.

4. What HTTP status codes should every API tester know?

2xx Success:

  • 200 OK — request succeeded
  • 201 Created — resource created, typically with Location header
  • 204 No Content — success with no response body (common for DELETE)

3xx Redirects:

  • 301 Moved Permanently — URL changed permanently
  • 302 Found — temporary redirect
  • 304 Not Modified — cached version is still valid

4xx Client Errors:

  • 400 Bad Request — malformed request, invalid parameters
  • 401 Unauthorized — missing or invalid authentication
  • 403 Forbidden — authenticated but not authorized
  • 404 Not Found — resource doesn't exist
  • 409 Conflict — resource state conflict (duplicate, version mismatch)
  • 422 Unprocessable Entity — valid syntax but semantic errors (validation failures)
  • 429 Too Many Requests — rate limit exceeded

5xx Server Errors:

  • 500 Internal Server Error — unhandled server exception
  • 502 Bad Gateway — upstream service error
  • 503 Service Unavailable — server overloaded or down for maintenance
  • 504 Gateway Timeout — upstream service didn't respond in time

5. What is the difference between 401 and 403?

401 Unauthorized means the request lacks valid authentication credentials — you're not identified. The response should include a WWW-Authenticate header indicating how to authenticate. 403 Forbidden means you are identified (authenticated) but not permitted to access the resource — you're identified but not allowed. A practical example: 401 when you call an endpoint without a token; 403 when you call an admin endpoint with a valid user token that lacks admin permissions.

6. What should you verify in an API test?

A comprehensive API test verifies: the HTTP status code matches the expected value, the response body structure matches the documented schema, required fields are present with correct data types, values are correct for the given input, response time is within acceptable thresholds, error responses include meaningful messages without exposing stack traces or internal details, headers are correct (Content-Type, CORS headers, cache headers), idempotent methods behave correctly on repeated calls, and the resource state after the operation is correct (a DELETE should actually remove the resource).

7. How do you test a REST API endpoint for creating a user?

Test cases include: happy path (valid body returns 201 with user object and correct Location header), duplicate email (returns 409 with descriptive error), missing required field (returns 400 or 422 with field-level error detail), invalid email format (returns 400/422), very long string values (boundary testing), special characters in name fields, empty strings, authentication required (returns 401 without token), authorization check (returns 403 if user doesn't have create permission), and verifying the created user can be retrieved via GET.

8. What is Postman and how do you use it for API testing?

Postman is an API testing platform that provides a GUI for constructing HTTP requests, organizing them into collections, writing test scripts, running collections, and generating documentation. Key features: pre-request scripts (for setup, like getting an auth token), test scripts (JavaScript assertions run after each request), environments (variable sets for different stages), collection runner (batch execution), Newman (CLI runner for CI/CD), and mock servers. A basic Postman test:

pm.test("Status code is 201", () => {
    pm.response.to.have.status(201);
});
pm.test("Response has user id", () => {
    const body = pm.response.json();
    pm.expect(body.id).to.be.a('string');
    pm.expect(body.email).to.eql(pm.environment.get("testEmail"));
});

9. How do you manage authentication in Postman for a test suite?

Use a pre-request script at the collection level to obtain an auth token and store it as an environment variable:

pm.sendRequest({
    url: pm.environment.get("baseUrl") + "/auth/token",
    method: "POST",
    header: {"Content-Type": "application/json"},
    body: {
        mode: "raw",
        raw: JSON.stringify({
            username: pm.environment.get("username"),
            password: pm.environment.get("password")
        })
    }
}, (err, response) => {
    pm.environment.set("authToken", response.json().token);
});

Then all requests in the collection use {{authToken}} in their Authorization header. This avoids hardcoding credentials and handles token expiry automatically.

10. What is the difference between API keys, Basic Auth, OAuth 2.0, and JWT?

API Keys are static tokens passed in headers or query parameters — simple but provide no user context and are hard to rotate. Basic Auth encodes username:password in Base64 in the Authorization header — simple but insecure without HTTPS and unsuitable for modern apps. OAuth 2.0 is an authorization framework with multiple flows (client credentials, authorization code, implicit) for delegated access — industry standard for third-party API access and SSO. JWT (JSON Web Token) is a self-contained token format that encodes claims (user ID, roles, expiry) and is signed — commonly used as the token format in OAuth 2.0 and session management. JWT tokens can be verified without a database lookup, which makes them scalable.

11. What is JWT and how would you test JWT authentication?

A JWT has three base64-encoded parts: header (algorithm), payload (claims), and signature. Test cases: request without token (401), expired token (401), tampered payload with original signature (401), token for wrong user accessing another user's resource (403), token with missing required claims (401), and valid token (200). Tools like jwt.io let you inspect and generate tokens for testing. A common vulnerability to test: accepting alg: none in the header — some implementations incorrectly skip signature verification in this case.

12. What is OAuth 2.0 and how do you test it?

OAuth 2.0 defines four flows. The Authorization Code flow (for web apps) involves redirecting the user to an authorization server, receiving a code, and exchanging it for tokens. The Client Credentials flow (for machine-to-machine) uses client ID and secret to get tokens directly. Test scenarios: expired access token handling, refresh token flow, token with insufficient scopes, CSRF protection in authorization code flow, redirect URI validation, and token storage security. For automation, use the Client Credentials flow where possible — it's simpler to automate than the Authorization Code flow which requires browser interaction.

13. What is contract testing and how does it differ from integration testing?

Contract testing verifies that the API contract (the agreed-upon interface) between a consumer and a provider is respected — without requiring both services to run simultaneously. The consumer writes tests that generate a "pact" (contract file), and the provider verifies against that pact independently. Pact and Spring Cloud Contract are standard tools. Integration testing requires deploying and running both services together to verify interaction. Contract testing is faster, can run in CI without external services, and gives earlier feedback on breaking changes. It's the recommended approach for microservices where separate teams own consumer and provider services.

14. What is OpenAPI (Swagger) and how does it relate to API testing?

OpenAPI (formerly Swagger) is a specification for describing REST APIs in a machine-readable format (YAML/JSON). It defines endpoints, request/response schemas, authentication methods, and examples. For API testing, the OpenAPI spec can: generate test cases automatically (tools like Schemathesis do this), validate that responses conform to the documented schema, serve as the contract in contract testing, generate mock servers for consumer testing, and produce documentation that testers use to understand the API. Testing against the spec ensures the API implementation matches its documentation.

15. What is Karate framework and what makes it different?

Karate is an open-source API testing framework that uses a Gherkin-like syntax but is specifically designed for REST/SOAP/HTTP testing — unlike Cucumber, which requires step definitions in Java. Tests are written directly in .feature files without glue code:

Feature: User API
  Scenario: Create user
    Given url 'https://api.example.com/users'
    And request { name: 'Test User', email: 'test@example.com' }
    When method post
    Then status 201
    And match response.id == '#string'
    And match response.email == 'test@example.com'

Karate also includes a UI testing module (using Playwright), performance testing (built-in), and mocking. It's particularly popular for teams that want readable API tests without Java glue code overhead.

16. How do you test API pagination?

Test that: the first page returns the correct number of items and a next cursor/link, subsequent pages return the correct items without duplicates or gaps, the last page is correctly identified, requesting a page beyond the last returns empty results or 404, the limit parameter is respected (including edge cases: 0, negative, very large), the offset or cursor is correctly applied, and concurrent modifications (inserting/deleting items) during pagination are handled gracefully (stable sort + consistent cursors).

17. What is idempotency and why does it matter for API testing?

An idempotent operation produces the same result regardless of how many times it's called. GET, PUT, DELETE are idempotent by design; POST is not. Testing idempotency: call a PUT endpoint twice with the same payload and verify the resource state is the same after both calls, call DELETE twice on the same resource and verify the second call returns 404 or 204 (not 500), and verify that a second POST with the same logical resource doesn't create a duplicate. Idempotency is critical for resilient systems — it allows clients to safely retry requests after network failures.

18. How do you test API rate limiting?

Send requests at a rate that exceeds the documented limit and verify: responses switch to 429 Too Many Requests at the correct threshold, the Retry-After header is present and accurate, the rate limit counter resets after the documented time window, and different authenticated users have independent limits (one user's limit doesn't affect another's). Also test that authenticated users get higher limits than unauthenticated users if the API promises this.

19. What is a mock server and when would you use one in API testing?

A mock server simulates an API endpoint and returns pre-configured responses. Use cases: testing your consumer before the provider API is built (enables parallel development), testing error and edge case scenarios that are hard to trigger in a real API (e.g., 503 responses), running tests without dependency on external services or network access, and deterministic testing of specific response conditions. Postman has a built-in mock server feature; WireMock is a popular standalone option for Java-based projects.

20. How do you test that an API properly handles concurrent requests?

Use tools like k6, Gatling, or Apache JMeter to send simultaneous requests and verify: shared resource operations (account balance updates, inventory decrements) are atomic and don't result in race conditions, unique constraints are enforced even under concurrent creation requests, the API doesn't deadlock or degrade disproportionately under concurrent load, and response times remain acceptable. Race condition bugs often don't appear in single-threaded tests — they require deliberately concurrent requests to surface.

21. What is GraphQL and how does testing it differ from REST testing?

GraphQL is a query language for APIs where clients specify exactly what data they need in a single request, using a strongly typed schema. Unlike REST (multiple endpoints, fixed responses), GraphQL uses a single endpoint with flexible queries. Testing differences: schema validation (validate queries against the schema), introspection (use the schema to generate test cases), testing nested queries and mutations, testing subscriptions (real-time), error handling (GraphQL always returns 200; errors are in the response body with an errors field), and N+1 query performance. Tools like Postman, Insomnia, and Apollo Studio support GraphQL testing.

22. What tools do you use for API performance testing?

  • k6 — JavaScript-based, cloud-native, good scripting flexibility, integrates well with CI/CD
  • Gatling — Scala-based, detailed HTML reports, good for complex scenarios
  • JMeter — Java-based, GUI + CLI, widely used, heavy but feature-rich
  • Locust — Python-based, easy to write distributed tests, web UI
  • Artillery — JavaScript/YAML, cloud-native, good for event-driven APIs

Key metrics to capture: response time (average, p50, p95, p99), throughput (requests per second), error rate, and connection pool behavior. Define performance budgets (SLAs) before testing — "under 500ms at p95 with 100 concurrent users" — so you have a pass/fail criterion.

23. How do you test CORS (Cross-Origin Resource Sharing) headers?

CORS headers control which origins can access the API from a browser. Test: preflight OPTIONS request returns correct Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, actual requests from allowed origins succeed, requests from disallowed origins are rejected (or rather, the browser enforces the policy based on response headers), credentials mode (Access-Control-Allow-Credentials: true) doesn't allow wildcards in Access-Control-Allow-Origin, and exposed headers (Access-Control-Expose-Headers) are correct.

24. What is schema validation in API testing?

Schema validation verifies that API responses conform to the documented structure — correct field names, correct data types, required fields present, no unexpected fields. Tools: JSON Schema validation (with AJV, jsonschema library), OpenAPI validators (Schemathesis, dredd), and assertion libraries (Chai, Jest matchers). Example in Postman:

const schema = {
    type: "object",
    required: ["id", "email", "createdAt"],
    properties: {
        id: { type: "string", format: "uuid" },
        email: { type: "string", format: "email" },
        createdAt: { type: "string", format: "date-time" }
    }
};
pm.test("Schema is valid", () => {
    pm.response.to.have.jsonSchema(schema);
});

25. How do you handle API versioning in tests?

API versioning strategies (URL versioning /v1/users, header versioning Accept: application/vnd.api+json;version=2, parameter versioning) require corresponding test organization. Maintain separate test suites or parameterized tests for each supported version. Test version-specific behavior differences, backward compatibility guarantees, and deprecation notices. When a new version is released, run the old version's tests to confirm backward compatibility, and add new tests for changed behavior.

26. What is API mocking vs. API stubbing?

Stubbing provides a canned response to a specific request — the stub returns pre-defined data without expectations about how it's called. Mocking goes further: it sets up expectations about which calls will be made, with what parameters, and how many times. After the test, the mock verifies those expectations were met. Use stubs when you need a dependency to return something; use mocks when you're specifically verifying that your code makes the right calls to a dependency.

27. How do you test API security beyond authentication?

Security testing includes: SQL injection in query parameters and request bodies, XSS in string fields, path traversal in URL parameters (e.g., ../../../etc/passwd), insecure direct object references (accessing another user's resources by changing an ID), mass assignment (sending extra fields that shouldn't be writable), sensitive data exposure in responses (passwords, full credit card numbers, PII), and HTTPS enforcement (HTTP should redirect or be rejected). Tools like OWASP ZAP and Burp Suite are designed for this kind of security-focused API testing.

28. What is the difference between end-to-end API testing and unit testing of API handlers?

Unit tests of API handlers test the handler function in isolation — mocking database calls, external services, and middleware. They're fast and precise for logic testing. End-to-end API tests make real HTTP requests against a running service, including actual database operations and integrations. E2E API tests are slower but verify the full stack including middleware, serialization, database queries, and network behavior. Both are needed — unit tests catch logic bugs early; E2E tests catch integration and deployment issues.

29. How do you test file download APIs?

Verify: the response status is 200, the Content-Type header matches the file type (e.g., application/pdf), the Content-Disposition header includes the expected filename, the Content-Length header matches the actual file size, the file content is correct (checksum or structural validation), large files stream correctly and don't cause memory issues, and authentication is enforced (unauthenticated requests get 401, unauthorized get 403).

30. What is API test data management?

Test data management for APIs involves: creating test data via API calls (not directly in the database, to ensure valid state), cleaning up test data after tests to avoid accumulation, using separate test environments with isolated databases, generating data with factories for consistency, and handling test-specific configuration (feature flags, test user accounts). The worst practice is using production data — it's risky, violates privacy, and makes tests non-deterministic.

31. How do you test webhooks?

Webhooks send HTTP POST requests to a callback URL when events occur. Testing challenges: you need a publicly reachable URL to receive webhooks (use tools like ngrok, webhook.site, or Requestbin in development). Test: the webhook fires when the triggering event occurs, the payload contains the correct data, the signature is correctly calculated (HMAC verification), your endpoint processes it correctly, retry behavior when your endpoint returns a non-2xx status, and duplicate delivery handling (webhooks may be delivered more than once).

32. What is a REST API test strategy for a microservices application?

A complete strategy includes: unit tests for API handler logic, contract tests (Pact) for each service-to-service interaction, integration tests for each service with its own database, component tests for each service's API against its spec, and selective end-to-end tests for the most critical user journeys. The goal is the test pyramid at every level — maximum fast, isolated tests; minimal slow, expensive E2E tests. CI runs unit and contract tests on every commit; integration and E2E tests run on merge or deployment.

33. How do you measure API test coverage?

Coverage dimensions: percentage of endpoints tested, percentage of HTTP methods per endpoint tested, percentage of documented response codes tested, percentage of documented error scenarios tested, and code coverage of API handler logic. Tools: OpenAPI-based tools like Schemathesis can automatically generate tests from spec coverage, Postman's API coverage reports show which endpoints have test scripts. High coverage percentage without meaningful assertions is misleading — focus on scenario coverage rather than just endpoint presence.

34. What are some common API bugs and how do you find them?

  • Broken authentication — endpoints accessible without tokens, weak token validation
  • IDOR (Insecure Direct Object References) — accessing other users' data by changing an ID
  • Missing validation — server accepts malformed data and stores or processes it incorrectly
  • Information disclosure — error messages reveal stack traces, internal paths, or database schemas
  • Rate limiting absent — brute force attacks possible
  • Inconsistent error format — some errors return HTML 404 pages instead of JSON
  • Wrong HTTP methods — DELETE that actually works via GET, or POST that doesn't create anything

The best way to find them: exploratory API testing with a tool like Postman combined with systematic negative testing.

35. How does HelpMeTest support API testing workflows?

HelpMeTest is a cloud-hosted QA platform ($100/month) that combines Robot Framework and Playwright with AI-powered test generation. For API testing, you can write tests in natural language describing the API behavior you want to verify, and the platform generates Robot Framework test cases using the RequestsLibrary. Tests run on HelpMeTest's cloud infrastructure with scheduling, alerting, and reporting built in. This is particularly useful for teams that want API test coverage without the overhead of setting up and maintaining a dedicated test execution infrastructure. The AI test generation helps create baseline test coverage for existing APIs quickly, which you then refine and extend.

Strong API testing skills demonstrate that you understand how modern applications actually work — not just how they look. The best API testers combine HTTP fundamentals, security awareness, and systematic test design with practical tool knowledge. In your interview, be ready to discuss real scenarios where API testing found bugs that UI testing missed.

Read more