QA interview guide

How would you test an API endpoint?

API endpoint questions reveal whether you can test beyond a successful 200 response. A strong answer covers request rules, contracts, security, backend side effects, failure modes, and client impact.

Practice this scenarioBrowse all questions

Write your own answer and compare it with senior QA coverage.

What interviewers expect

What interviewers expect

Interviewers expect payload validation, required fields, status codes, response schema, authentication, authorization, idempotency where relevant, data persistence, error format, rate limiting, logs, metrics, and performance.

Checklist

Checklist

Use these practical prompts to build a complete answer. Strong interview responses usually include functional behavior, negative cases, security, backend/data risks, UX, accessibility, and reliability.

Contract and functional behavior

  • Valid minimal request returns the expected success status and response body.
  • Valid full request handles optional fields, defaults, generated ids, timestamps, and server-calculated values.
  • Response schema, field types, required fields, nullable fields, and enum values match the contract.
  • Headers, content type, versioning, and correlation ids behave as documented.
  • The endpoint produces the expected backend side effect or no side effect for read-only operations.

Validation and negative cases

  • Missing required fields, empty values, invalid formats, boundary lengths, and wrong data types are rejected.
  • Malformed JSON, unsupported content type, duplicate records, invalid ids, and unknown fields are handled.
  • Unicode, special characters, whitespace-only values, and very large payloads are tested.
  • Correct 400, 401, 403, 404, 409, 422, and 500-level behavior is verified where relevant.
  • Error responses are consistent, safe, and useful for clients.

Security and authorization

  • Missing, invalid, expired, and revoked tokens are rejected.
  • Role, permission, tenant, workspace, and ownership restrictions are enforced on the backend.
  • Injection, mass assignment, parameter tampering, IDOR, and sensitive response data are checked.
  • Rate limiting, abuse protection, replay protection, and audit logging work where needed.
  • Secrets, tokens, passwords, and internal errors are not logged or returned.

Reliability, data, and performance

  • Database persistence, transaction rollback, consistency, and fetch-after-write behavior are verified.
  • Dependency failures, timeout, retry behavior, queue failures, and partial failures are handled.
  • Idempotency or duplicate-submit behavior is tested when the endpoint creates or charges data.
  • Response time, high volume, concurrency, and payload size stay within SLA.
  • Metrics, diagnostic logs, alerts, and traceability support debugging without leaking data.

Complete interview coverage checklist

Aim to mention 20-40 concrete checks. This expanded list helps you turn a short answer into a structured senior-style response.

Valid minimal request returns the expected success status and response body.
Valid full request handles optional fields, defaults, generated ids, timestamps, and server-calculated values.
Response schema, field types, required fields, nullable fields, and enum values match the contract.
Headers, content type, versioning, and correlation ids behave as documented.
The endpoint produces the expected backend side effect or no side effect for read-only operations.
Missing required fields, empty values, invalid formats, boundary lengths, and wrong data types are rejected.
Malformed JSON, unsupported content type, duplicate records, invalid ids, and unknown fields are handled.
Unicode, special characters, whitespace-only values, and very large payloads are tested.
Correct 400, 401, 403, 404, 409, 422, and 500-level behavior is verified where relevant.
Error responses are consistent, safe, and useful for clients.
Missing, invalid, expired, and revoked tokens are rejected.
Role, permission, tenant, workspace, and ownership restrictions are enforced on the backend.
Injection, mass assignment, parameter tampering, IDOR, and sensitive response data are checked.
Rate limiting, abuse protection, replay protection, and audit logging work where needed.
Secrets, tokens, passwords, and internal errors are not logged or returned.
Database persistence, transaction rollback, consistency, and fetch-after-write behavior are verified.
Dependency failures, timeout, retry behavior, queue failures, and partial failures are handled.
Idempotency or duplicate-submit behavior is tested when the endpoint creates or charges data.
Response time, high volume, concurrency, and payload size stay within SLA.
Metrics, diagnostic logs, alerts, and traceability support debugging without leaking data.
Structure your answer: Start with the endpoint contract: method, URL, payload, success status, and response schema.
Structure your answer: Add validation and negative cases: missing fields, bad formats, malformed JSON, duplicates, and status codes.
Structure your answer: Add security: authentication, authorization, tenant isolation, injection, mass assignment, and safe errors.
Structure your answer: Close with data consistency, dependency failures, idempotency, performance, logs, metrics, and observability.
Do not miss: Response schema and error contract.
Do not miss: Authorization on the backend, not only UI access.
Do not miss: Rollback and consistency after dependency failures.
Do not miss: Observability, correlation ids, and safe logs.

Ready to practice?

Practice this scenario interactively

Write your own answer and compare it with senior QA coverage.

Practice this scenario

Answer structure

Strong answer structure

  1. Start with the endpoint contract: method, URL, payload, success status, and response schema.
  2. Add validation and negative cases: missing fields, bad formats, malformed JSON, duplicates, and status codes.
  3. Add security: authentication, authorization, tenant isolation, injection, mass assignment, and safe errors.
  4. Close with data consistency, dependency failures, idempotency, performance, logs, metrics, and observability.

Common missed areas

Common missed risks

Response schema and error contract.
Authorization on the backend, not only UI access.
Rollback and consistency after dependency failures.
Observability, correlation ids, and safe logs.

Answer template

Use this interview answer template

I would start with the API contract and a valid request, then cover required fields, schema validation, status codes, auth, permissions, error responses, data persistence, idempotency, dependency failures, security, rate limiting, performance, logs, and metrics.

Use it as a structure, then replace the examples with specific checks for the feature you are discussing.

Common weak answer

“I would test valid and invalid cases.”

This is too generic because it does not show risk thinking. A stronger answer names the happy path, negative cases, security risks, backend/data behavior, UX/accessibility, and reliability concerns that matter for this exact scenario.

Examples

Weak answer vs stronger answer

Weak answer
“I would test that the API returns 200.”

A status code alone does not prove the endpoint is correct. It misses contracts, validation, auth, side effects, error format, data consistency, and performance.

Stronger answer
“I would test the method, URL, valid minimal and full payloads, expected status code, response schema, generated fields, required and optional fields, missing fields, invalid formats, wrong types, malformed JSON, duplicate data, auth missing, auth expired, permission denied, tenant isolation, injection, mass assignment, sensitive data not returned, safe error format, database side effects, rollback on failure, dependency timeout, idempotency, concurrent requests, rate limiting, response time, logs, metrics, and alerts.”

FAQ

Frequently asked questions

What should I mention first when answering "How would you test an API endpoint?"

Start with the endpoint contract: method, URL, payload, success status, and response schema.

Should I include negative and edge cases?

Missing required fields, empty values, invalid formats, boundary lengths, and wrong data types are rejected. Malformed JSON, unsupported content type, duplicate records, invalid ids, and unknown fields are handled.

Should I include security, API, or backend risks?

Missing, invalid, expired, and revoked tokens are rejected. Role, permission, tenant, workspace, and ownership restrictions are enforced on the backend.

What are common missed risks?

Response schema and error contract. Authorization on the backend, not only UI access. Rollback and consistency after dependency failures. Observability, correlation ids, and safe logs.

How can I practice this answer?

Use the interactive how would you test an api endpoint? challenge to write your own answer, get checklist-based feedback, and compare your coverage with stronger QA thinking.

Practice

Practice this scenario interactively

Write your own answer and compare it with senior QA coverage.

Practice this scenario