API Testing Interview Questions

What should I focus on for my API testing interview?

Can I explain how I test a REST API?

The most common question was how to test a REST API and which checks matter. It appeared in 10 of 69 interviews. Can you describe what you would test, rather than just name a tool?

• Can you explain what makes up an HTTP request and response?
• Can you explain methods, status codes, payloads, and idempotency?
• Can you describe tests for a user registration API beyond a successful status code?
• Can you explain when you would choose endpoint, integration, or end-to-end tests?

For the registration example, name the request rules and response checks you would include. This connects your HTTP knowledge to a specific testing task.

Can I explain what I check in requests and responses?

Validation questions covered JSON fields, schemas, data types, payload rules, and business checks. They also covered responses whose values change or cannot be predicted exactly. Check whether your answer goes beyond an expected status code.

• Which fields, types, and payload rules would you check?
• How would you check a response when you cannot predict its exact values?
• How would you group and diagnose payload validation failures?

Security questions covered authentication, role-based access, login flows, and exposed secrets. Can you explain what 401 means and when missing or expired tokens should produce it? Can you describe how you would test access for different roles?

Can I describe how I use Postman and automation tools?

How candidates use Postman came up in 4 of 69 interviews. The wider Postman topic included collections, variables, scripts, request chaining, certificates, and reusable test suites.

Can you walk through importing an API, sending a request, and checking its response? Explain how you would use variables and scripts to chain requests. Then describe how you would make those tests reusable.

Automation questions also covered REST Assured, SoapUI, Playwright, language choices, and framework design. Can you explain why you would choose your tool over another? Can you describe what you would change when moving tests between tools?

Can I test integrations and investigate problems?

Integration and contract testing appeared in 15 of 69 interviews. Questions covered external services, mocks, recorded responses, contracts, OpenAPI, gRPC, Kafka, and webhooks.

• Can you explain how you use mocked responses in tests?
• What would you check across a frontend-to-backend workflow?
• How would you investigate a request that works in Postman but not in an application?
• How would you separate client problems from server problems when investigating a timeout?

Performance questions covered load-test design, throughput, and slow responses. Can you describe a load test and explain how your checks would differ for synchronous and asynchronous endpoints?

Who gets asked API Testing

The 20 most asked API Testing questions

Counted by interview, not by mention: a question asked twice in one conversation counts once.

1. How do you test a REST API, and what checks do you consider essential?

   Asked in 10 of 69 interviews · last asked Sep 30 · Scenario · Mid-level

   Show answer

   I test a REST API against its contract using valid, invalid, and boundary inputs. I check status codes, headers, response data, and schema, then confirm expected database changes or other effects. I also test authentication, permissions, error handling, and response times under expected load.

   • Test supported methods, paths, parameters, and request bodies against the API contract.
   • Verify actual field values and business rules, not just a successful status code.
   • Check missing credentials, expired tokens, and attempts to access another user's data.
   • Test retries and repeated requests for unintended duplicate changes where idempotency is required.

   What the interviewer checks: The interviewer checks whether you cover correct behavior, failures, security, and side effects rather than only successful responses.

   Other ways it was asked

   • “How do you test an API, and what specifically do you verify?”
   • “What aspects of an API would you test?”
   • “What validations do you perform for an API?”

2. How do you use Postman when testing APIs?

   Asked in 4 of 69 interviews · last asked Sep 21 · Tooling · Junior

   Show answer

   I use Postman to send requests and check status codes, headers, and response bodies. I group requests into collections and use environment variables for different servers. I add JavaScript assertions and run collections to see which tests pass or fail. I use Postman CLI or Newman for CI, but dedicated tools are better for heavy load testing.

   • Set the request method, URL, headers, authentication, and body.
   • Test valid inputs, invalid inputs, and missing or incorrect credentials.
   • Use assertions to check expected results; a successful HTTP status alone does not prove correctness.
   • Large collections can be harder to maintain and review than code-based test suites.

   What the interviewer checks: The interviewer checks whether you can use Postman for both manual testing and repeatable automated checks.

   Other ways it was asked

   • “What do you use Postman for?”
   • “What are the disadvantages of testing APIs with Postman?”
   • “How can you use Postman to automate API tests and verify which requests pass or fail?”

3. What is an HTTP request, and what components make up HTTP requests and responses?

   Asked in 3 of 69 interviews · last asked Oct 3 · Concept · Junior

   Show answer

   An HTTP request is a message a client sends to a server to ask for data or an action. It contains a method, a request target (usually a path and optional query), headers, and an optional body. An HTTP response contains a status code, headers, and an optional body.

   • Methods include GET, POST, PUT, and DELETE; a POST request often carries data in its body.
   • Headers carry details such as authentication, content type, and caching rules.
   • In HTTP/1.1, the request line and response status line also include the HTTP version.

   What the interviewer checks: The interviewer is checking whether you can identify request and response parts and explain their roles.

   Other ways it was asked

   • “What components, other than the status code, are included in an HTTP request or response?”
   • “What components are included in an HTTP POST request?”
   • “What is an API request?”

4. How do you approach backend testing, including APIs and messaging systems?

   Asked in 2 of 69 interviews · last asked Jul 16 · Tooling · Mid-level

   Show answer

   I test backend logic, APIs, database changes, and message flows at unit, integration, and end-to-end levels. For APIs, I check response data, status codes, validation, and access control. For messaging, I check delivery, retries, duplicate handling, and ordering where required. I also test failures and performance under load.

   • Use isolated test data and verify stored data and other side effects.
   • Check API contracts, error responses, authentication, and permissions.
   • For Kafka, ordering is within a partition, not across the whole topic.
   • Test asynchronous results with a timeout, rather than fixed waits.

   What the interviewer checks: The interviewer checks whether you can test backend behavior across services, including failures and asynchronous processing.

   Other ways it was asked

   • “What approaches do you use to test backend systems, including APIs and Kafka?”
   • “What types of back-end testing do you perform, and how do you approach them?”

5. How would you test a user registration API beyond checking for a successful status code?

   Asked in 2 of 69 interviews · last asked Oct 7 · Scenario · Mid-level

   Show answer

   I would check the response body and confirm that the user is stored correctly. I would test missing fields, invalid emails, weak passwords, duplicate accounts, and input length limits. I would also check that passwords are securely hashed, responses never expose them, and verification emails work if required.

   • Check status codes and response fields against the API contract, not just for HTTP 200.
   • Failed requests should not create users or leave partial data.
   • Test duplicate handling, including email case rules defined by the API.
   • Check that clients cannot assign themselves admin roles and that registration rate limits work.

   What the interviewer checks: The interviewer is checking whether you cover data correctness, validation, security, and side effects beyond the HTTP status.

   Other ways it was asked

   • “How would you test a user registration API?”
   • “What do you typically validate in a user registration API?”
   • “Beyond checking for an HTTP 200 response, what types of tests would you perform on a user registration API?”

6. How would you diagnose and categorize request payload validation failures in an Open Finance API?

   Asked in 2 of 69 interviews · last asked Jul 17 · Scenario · Mid-level

   Show answer

   I would compare the failing request with the endpoint’s schema and Open Finance specification version, then inspect the response errors and sanitized logs. I would group failures into malformed JSON, schema violations, and business rule failures. I would fix one issue at a time and repeat the sandbox test to confirm the cause.

   • Check required fields, data types, allowed values, formats, and unexpected fields.
   • Check rules between fields, such as whether an amount and currency combination is valid.
   • Match error codes and field paths to the specification; HTTP status alone may not identify the cause.
   • Keep authentication, permission, and consent failures separate from payload validation failures.

   What the interviewer checks: The interviewer is checking whether you can trace failures to specific fields and distinguish structural errors from business rule failures.

   Other ways it was asked

   • “A bank client is failing an Open Finance sandbox test related to payload validation. How would you diagnose the issue?”
   • “How would you identify and categorize validation failures in an Open Finance request payload?”

7. What does HTTP 401 mean, and when should missing or expired authentication tokens produce it?

   Asked in 2 of 69 interviews · last asked Jul 31 · Concept · Junior

   Show answer

   HTTP 401 means the request lacks valid authentication credentials. A protected endpoint should return it when a required token is missing, invalid, or expired. HTTP 403 usually means authentication succeeded, but the caller lacks permission. Postman shows these responses from the server; it does not decide the status code.

   • Missing tokens should not cause 401 on endpoints that allow anonymous access.
   • A 401 response must include a WWW-Authenticate header with an applicable authentication challenge.
   • For an expired token, obtain a valid token before retrying.
   • A valid token with insufficient permissions usually results in 403, not 401.

   What the interviewer checks: The interviewer is checking whether you distinguish authentication failures from permission failures and know when tokens are required.

   Other ways it was asked

   • “What does a 401 error mean when you make a request using Postman?”
   • “What does a 403 error mean when you make a request using Postman?”
   • “What response code would you expect if the request did not include an authentication token or the token was expired?”

8. What is API mocking, and how do you use mocked responses in tests?

   Asked in 2 of 69 interviews · last asked May 28 · Scenario · Mid-level

   Show answer

   API mocking means replacing a real API with a fake service that returns controlled responses. In tests, I set up expected requests and responses, send calls to the mock, and check how my code handles them. This lets me test success, errors, and delays without depending on the real service.

   • Define matching requests, response status codes, headers, and bodies.
   • Use tools such as WireMock, MockServer, or Postman mock servers.
   • Test failure cases that are hard to trigger with the real API.
   • Keep mocks aligned with the API contract; they do not replace tests against the real service.

   CodeCopy

   Mock: GET /users/42 returns 404 with {"error":"User not found"}.
   Test: Call the user lookup through the mock.
   Check: The app shows "User not found" instead of crashing.

   What the interviewer checks: The interviewer is checking whether you can isolate API dependencies and verify how your code handles controlled responses.

   Other ways it was asked

   • “What is API mocking, and why is it used?”
   • “How can you test API behavior with mocked responses?”
   • “What tools can you use to mock API responses?”

9. What response code would you expect if the client did not have permission to access the requested resource?

   Asked once · last asked Jul 16 · Concept · Junior

   Show answer

   I would expect 403 Forbidden if the client does not have permission to access the resource. If the question means the resource does not support the requested HTTP method, I would expect 405 Method Not Allowed instead.

   • 403 means the server refuses access, often because the client lacks permission.
   • 401 means valid authentication credentials are missing.
   • 405 responses must include an Allow header listing the resource’s supported methods.

   What the interviewer checks: The interviewer is checking whether you can distinguish permission, authentication, and HTTP method errors.

   Other ways it was asked

   • “What response code would you expect if the HTTP method in the request were not supported by the resource?”

10. Why is REST used more often for automation?

    Asked once · last asked Jul 16 · Concept · Mid-level

    Show answer

    REST APIs are often easier to automate because they use standard HTTP methods and work with common test tools. Their often-used JSON payloads are easy to build and check. Stateless requests help tests run independently, but REST is not always the best choice for every system.

    • Common HTTP clients can send requests and check status codes, headers, and response bodies.
    • REST often uses JSON, but it does not require it.
    • Stateless requests still need test data setup and cleanup when they change server data.
    • Compared with SOAP, REST often needs less message setup.

    What the interviewer checks: The interviewer is checking whether you can explain why REST is practical for automation without treating it as universally better.

11. What is idempotency in HTTP methods and how do you verify idempotency in automated tests?

    Asked once · last asked Jul 21 · Scenario · Mid-level

    Show answer

    Idempotency means repeating the same request has the same intended effect on the server as sending it once. In automated tests, I start with known data, send the request once, then repeat it and compare the resulting state and intended side effects. Response codes or bodies may differ without breaking idempotency.

    • GET, HEAD, OPTIONS, TRACE, PUT, and DELETE are defined as idempotent.
    • POST and PATCH are not guaranteed to be idempotent; check the API contract.
    • Check resource state and duplicate changes, such as extra payments, not just responses.
    • A repeated DELETE may return 404 after an initial 204; the resource is still absent.

    What the interviewer checks: The interviewer checks whether you distinguish server effects from responses and can test repeated requests reliably.

12. Which HTTP response codes should REST API automation tests cover?

    Asked once · last asked Jul 23 · Concept · Junior

    Show answer

    REST API tests should cover the status codes defined by the API contract, for success and failure cases. Common codes include 200, 201, 204, 400, 401, 403, 404, 409, 429, and 500. Test redirects and other codes when relevant, and check response bodies and headers too.

    • Check the exact expected code: 200 means success, 201 means created, and 204 means success without response content.
    • Test 401 for missing or invalid authentication, and 403 for refused access, according to the contract.
    • Cover invalid input, missing resources, conflicts, and rate limits where supported.
    • Test relevant redirects and server failures; use controlled faults or mocks rather than disrupting shared systems.

    What the interviewer checks: The interviewer checks whether you cover both successful and failed requests and verify the API contract.

13. How do PUT and PATCH differ, and should PUT be used for partial updates?

    Asked once · last asked Apr 30 · Concept · Junior

    Show answer

    PUT replaces the target resource’s state with the supplied representation. PATCH applies a set of changes, so it is the right choice for partial updates. An API may support partial updates through PUT, but that is a custom contract, not standard PUT semantics.

    • PUT is idempotent: repeating the same request has the same intended effect as sending it once.
    • PATCH is not always idempotent; it depends on the changes requested.
    • With PUT, do not assume omitted fields stay unchanged; check the API contract.

    What the interviewer checks: The interviewer checks whether you understand replacement versus partial changes, idempotency, and API-specific behavior.

    Other ways it was asked

    • “Can you partially update data using the PUT method?”
    • “If PUT can do the same thing, why do you need PATCH?”

14. What protocols are commonly used for APIs?

    Asked once · last asked Jul 16 · Concept · Junior

    Show answer

    Most web APIs use HTTP or HTTPS, which is HTTP secured with TLS. WebSocket supports real-time, two-way communication. gRPC normally uses HTTP/2. REST is an API style, GraphQL is a query language, and SOAP is a messaging protocol often carried over HTTP.

    • HTTPS encrypts API traffic and helps verify the server's identity.
    • WebSocket keeps a connection open so either side can send messages.
    • gRPC supports remote function calls and streaming, usually with Protocol Buffers.
    • SOAP uses XML messages; REST and GraphQL are not transport protocols.

    What the interviewer checks: The interviewer checks whether you know common API protocols and can distinguish them from API styles and frameworks.

15. What do you understand by payload in RESTful web services?

    Asked once · last asked Jul 16 · Concept · Junior

    Show answer

    A payload is the data carried in the body of an HTTP request or response. In RESTful web services, it is often JSON, but it can also be XML, text, or binary data. Headers and the URL are not part of the payload, and some messages have no payload.

    • A request payload can send data to create or update a resource.
    • A response payload can contain resource data or error details.
    • The Content-Type header describes the format of the body.

    CodeCopy

    POST /users HTTP/1.1
    Host: api.example.com
    Content-Type: application/json
    Content-Length: 14
    
    {"name":"Ana"}

    What the interviewer checks: The interviewer is checking whether you can distinguish body data from headers and URL parameters.

16. Can you also tell me about API testing?

    Asked once · last asked Oct 12 · Concept · Junior

    Show answer

    API testing checks whether an API works as expected by sending requests and checking responses. I check status codes, returned data, headers, and changes to stored data. I test valid and invalid inputs, authentication, and access permissions, without using the user interface.

    • Check responses against the API contract and business rules.
    • Test missing fields, invalid values, and error responses.
    • Check that users cannot access data or actions without permission.
    • Automate repeatable tests and keep test data isolated.

    What the interviewer checks: The interviewer is checking whether you understand what API testing covers beyond successful requests.

17. If the database provides last week’s and this week’s sales values through an API, but the percentage change is calculated on the front end, how would you define your testing strategy?

    Asked once · last asked Apr 1 · Scenario · Senior

    Show answer

    I would test the API data and the front-end calculation separately, then test them together. I would check that the API returns the correct sales for each week and that the front end calculates and displays the change correctly. I would also test rounding, missing values, API errors, and the agreed behavior when last week’s sales are zero.

    • Check API sales against known database values, including week boundaries and time zones.
    • Use (this week − last week) / last week × 100.
    • Test increases, decreases, no change, and zero sales last week.
    • Check displayed signs, rounding, loading states, and error handling.

    CodeCopy

    Last week: 200
    This week: 250
    Expected change: (250 - 200) / 200 × 100 = +25%
    If last week is zero, check the agreed display rule; do not divide by zero.

    What the interviewer checks: The interviewer is checking whether you separate API data checks from front-end logic checks and cover the full user flow.

18. How would you test a GET method in an API?

    Asked once · last asked Apr 23 · Scenario · Junior

    Show answer

    I would send GET requests with valid and invalid inputs, then check the status code, headers, and response data against the API contract. I would test filters, sorting, and pagination if supported. I would also check access control, response time, and that the request does not change business data.

    • Check response values, field types, and required fields, not just the status code.
    • Test missing records, invalid parameters, empty results, and pagination boundaries.
    • Check requests with missing credentials and users without permission.
    • GET should not change business data; logging and metrics are allowed side effects.

    What the interviewer checks: The interviewer wants to see whether you cover correctness, error cases, security, and GET behavior.

19. What are request tests and integration tests, and when would you use each?

    Asked once · last asked Jun 23 · Concept · Mid-level

    Show answer

    Request tests check an API endpoint by sending a request and checking its response. Integration tests check whether connected parts, such as the API and database, work together. Use request tests for endpoint behavior and integration tests for interactions between parts. They can overlap when request tests use real connected parts.

    • Request tests can check status codes, headers, response bodies, validation, and access rules.
    • Integration tests can catch database, configuration, and service connection problems.
    • Mocked dependencies cannot prove that real connections work.
    • Test names and boundaries vary by framework and team.

    What the interviewer checks: The interviewer checks whether you understand test scope and can choose tests for endpoint behavior or component interactions.

20. How do you approach writing test cases for a PUT endpoint versus a PATCH endpoint?

    Asked once · last asked Jul 21 · Scenario · Mid-level

    Show answer

    I test PUT as a full replacement and PATCH as a partial update, following the API contract. For PUT, I check required fields and what happens to omitted fields. For PATCH, I check that only targeted fields change. For both, I verify the response, saved data, validation, and permissions.

    • Repeating PUT must have the same intended effect; PATCH may not be idempotent.
    • PATCH tests depend on the patch format, especially how it handles null values and field removal.
    • Check missing resources: PUT may create them if supported; PATCH behavior depends on the contract.
    • A failed PATCH must not leave a partially applied update.

    What the interviewer checks: The interviewer checks whether you turn replacement and partial-update rules into tests for actual data changes.

    Other ways it was asked

    • “How do you approach writing test cases for a GET endpoint versus a POST endpoint?”

Related interview questions

• QA Engineer interview questions
• Software Engineer interview questions
• Business Analyst interview questions
• Cybersecurity interview questions
• Project Manager interview questions
• Customer Service interview questions
• Manual Testing interview questions
• Automation Testing interview questions
• Agile and Scrum interview questions
• Salesforce interview questions

How this list is made

Every question here was asked by a real interviewer in a real job interview that a candidate ran MeetAssist in. After the call, the interviewer's questions are pulled from the transcript. Practice sessions, tests, exams and anything that was not a job interview are dropped.

Questions are rewritten so they make sense on their own: names of people, employers and clients are removed, and speech-to-text mistakes are fixed. Small talk, logistics and questions about one candidate's own résumé are left out. Rephrasings of the same question are merged, and the count is the number of different interviews it came up in.

The interviews come from candidates who use MeetAssist, so they lean towards software, data and AI roles: the shares describe these interviews, not every API Testing interview. Answers to the most asked questions are written and checked by an editor; a "common mistake" is shown only when reviews of real answers in these interviews show it, with the count.

69 interviews, 44 candidates, Jan 2026 to Oct 2026. Updated every month with new interviews.