Skip to content
RED SAGSkills

API Testing interview questions and answers

API testing questions check whether you can test a service without a UI: status codes, contracts, authentication and the edge cases that break integrations.

Below are 60 API Testing questions with the correct answer and a short explanation, grouped from fresher to experienced level. Try each one before you open the answer.

Take the API Testing MCQ testPractise 148+ API Testing questions for points

What API Testing interviews usually check

  • ✓HTTP methods, status codes and headers
  • ✓Positive, negative and boundary test cases
  • ✓Auth tokens, sessions and permission checks
  • ✓Contract and schema validation
  • ✓Tools such as Postman, REST Assured and automated suites

API Testing interview questions for freshers easy

1. 401 vs 403

A logged-in normal user calls an admin-only endpoint. Which status code is correct?

  1. A.401 Unauthorized, because the user is not logged in
  2. B.404 Not Found, always
  3. C.500 Internal Server Error
  4. D.403 Forbidden, because the user is known but not allowed
Show answer

Answer: D. 403 Forbidden, because the user is known but not allowed

401 means the request has no valid authentication, such as a missing or expired token. 403 means the server knows who you are but you do not have permission. Some APIs return 404 to hide that a resource exists, but that must be a documented choice.

2. A successful delete with no body

DELETE /cart/items/42 succeeds and the API returns no body. Which status code fits best?

  1. A.201 Created
  2. B.202 Accepted
  3. C.404 Not Found
  4. D.204 No Content
Show answer

Answer: D. 204 No Content

204 means the request worked and there is nothing to return. 200 with a body is also fine if the API sends one. 201 is for creation, and 202 means the work is accepted but not finished yet.

3. Fetching an ID that does not exist

You call GET /customers/999999 and no such customer exists. What should a well-designed API return?

  1. A.200 OK with an empty body
  2. B.500 Internal Server Error
  3. C.404 Not Found
  4. D.400 Bad Request
Show answer

Answer: C. 404 Not Found

A missing resource should give 404, so clients can tell "not found" apart from "found but empty". A 500 here means the server crashed on a missing record, which is a bug to report.

4. Where to find the new resource

POST /invoices returns 201 Created. Which header should tell you the URL of the new invoice?

  1. A.Location
  2. B.Referer
  3. C.Host
  4. D.Content-Location only on errors
Show answer

Answer: A. Location

With 201, the Location header usually holds the URL of the created resource, such as /invoices/8812. A good test checks it is present and that a GET on it returns the new invoice.

5. Basic auth and Base64

An API uses HTTP Basic auth. The header is "Authorization: Basic cmF2aTpwYXNzMTIz". What should a tester know?

  1. A.The password is strongly encrypted
  2. B.The header is unique for each request
  3. C.Base64 is easily decoded, so HTTPS is a must
  4. D.Basic auth cannot be used in Postman
Show answer

Answer: C. Base64 is easily decoded, so HTTPS is a must

Base64 is an encoding, not encryption; that header decodes straight to "ravi:pass123". Over plain HTTP anyone on the path can read it. Tests should confirm the API refuses plain HTTP.

6. Postman environments

Why do testers use Postman environments such as "dev", "staging" and "uat"?

  1. A.To run requests faster on a powerful server
  2. B.To switch base URLs and keys without editing requests
  3. C.To store the test results of each run
  4. D.To share the collection with other teams
Show answer

Answer: B. To switch base URLs and keys without editing requests

An environment holds variables like {{baseUrl}} and {{apiKey}}. Requests refer to the variables, so switching environment runs the same collection against another server.

7. Getting a 500 from an API

You send a request with a very long name and the API returns 500 Internal Server Error. What does this usually mean?

  1. A.The client sent a valid request that succeeded
  2. B.The token has expired and must be renewed
  3. C.The server failed to handle the input; log a bug
  4. D.The request was cached by a proxy
Show answer

Answer: C. The server failed to handle the input; log a bug

Bad input should get a 4xx answer like 400 with a clear message. A 500 means the server hit an unhandled error. Report it with the request, response and time so developers can check server logs.

8. Works in Postman, fails in browser

An API call works in Postman, but the same call from the web app fails with a CORS error. Why?

  1. A.Postman uses a newer version of HTTP
  2. B.Browsers enforce CORS; Postman does not
  3. C.The web app sends the wrong password
  4. D.Postman caches responses from the server
Show answer

Answer: B. Browsers enforce CORS; Postman does not

CORS is a browser security rule: the server must send headers like Access-Control-Allow-Origin for that site. Postman is not a browser, so it skips the check. Test CORS from a browser or by checking the headers directly.

9. What HEAD returns

What should a HEAD request to /files/report.pdf return?

  1. A.The same headers as GET, but no body
  2. B.The full file, like a normal GET
  3. C.Only the first 100 bytes of the file
  4. D.A list of methods the URL allows
Show answer

Answer: A. The same headers as GET, but no body

HEAD asks for the headers a GET would return, without the body. It is handy to check Content-Length, Content-Type or Last-Modified cheaply. A test can compare HEAD and GET headers for the same URL.

10. The OPTIONS preflight

A browser app sends PUT with a custom header to another domain. Before the PUT, the browser sends an OPTIONS request. Why?

  1. A.It checks the user's password before sending
  2. B.It downloads the API documentation first
  3. C.It deletes any cached responses for that URL
  4. D.It is a CORS preflight asking if the call is allowed
Show answer

Answer: D. It is a CORS preflight asking if the call is allowed

For non-simple cross-origin requests, browsers send an OPTIONS preflight. The server must answer with headers like Access-Control-Allow-Methods and Allow-Headers. If the preflight fails, the real request is never sent.

11. Testing two API versions

An API serves both /v1/orders and /v2/orders. After a release that only changes v2, what should regression cover?

  1. A.Only v2, since v1 was not touched
  2. B.Only v1, since more clients use it
  3. C.Both v1 and v2, since shared code may have changed
  4. D.Neither, since versioning prevents bugs
Show answer

Answer: C. Both v1 and v2, since shared code may have changed

Versions often share services, models and databases. A change meant for v2 can break v1 through shared code. Running key v1 tests protects existing clients until v1 is retired.

12. A health check endpoint

An API has GET /health. What should a good test check?

  1. A.It returns the full list of users in the system
  2. B.It always returns 200, whatever the server state
  3. C.It needs an admin token before anyone can call it
  4. D.It reports unhealthy when a key dependency is down
Show answer

Answer: D. It reports unhealthy when a key dependency is down

Load balancers and monitors use health checks to route traffic. A check that always says 200 hides outages. Tests should stop the database or a key service and check the endpoint reports unhealthy.

13. Keeping tokens out of Git

A tester exports an environment with a production API key in it and commits it to Git. What is the better practice?

  1. A.Keep secrets as secret or vault values, out of exports
  2. B.Commit it, since the repository is private
  3. C.Put the key in the collection description
  4. D.Email the key to the team instead
Show answer

Answer: A. Keep secrets as secret or vault values, out of exports

Exports and repositories get shared and leaked. Postman supports secret-type variables and Postman Vault, and CI should inject keys from its secret store. Any key that was committed should be rotated.

14. Checking response time

Which Postman check fails if the response takes 800 ms or more?

  1. A.pm.response.to.have.status(800)
  2. B.pm.expect(pm.response.size).to.be.below(800)
  3. C.pm.response.to.have.header("800")
  4. D.pm.expect(pm.response.responseTime).to.be.below(800)
Show answer

Answer: D. pm.expect(pm.response.responseTime).to.be.below(800)

pm.response.responseTime holds the time in ms, so below(800) asserts it. This is a quick guard, but single runs are noisy, so real performance targets belong in load tests that use percentiles.

15. Checking a filter

GET /orders?status=PAID returns 25 orders. What must the test check besides the status code?

  1. A.Every returned order has status PAID
  2. B.The response has exactly 25 orders always
  3. C.The first order has the lowest ID
  4. D.The response took under 50 ms
Show answer

Answer: A. Every returned order has status PAID

A filter bug often returns extra items that do not match. Loop over the results and check each status, and also check a known PAID order is included. The count changes as data changes, so it is a weak check alone.

16. Key names and letter case

The contract says the response field is "orderId", but the API returns "OrderID". Is this a defect?

  1. A.No; JSON parsers ignore the case of keys
  2. B.No; only the values must match the contract
  3. C.Only if the value is different from the spec too
  4. D.Yes; JSON keys are case-sensitive, so clients miss it
Show answer

Answer: D. Yes; JSON keys are case-sensitive, so clients miss it

JSON keys are case-sensitive, so "orderId" and "OrderID" are different fields. A client reading orderId gets undefined. Schema validation or exact key checks catch this kind of mismatch.

17. A list with no results

GET /customers/5/orders for a customer with no orders returns {"orders": null}. The contract shows an array. What is better?

  1. A.404 Not Found for the customer
  2. B.500, since there is no data
  3. C.{"orders": []}, an empty array
  4. D.{"orders": "none"} as a string
Show answer

Answer: C. {"orders": []}, an empty array

An empty array keeps the type the same, so clients can loop without null checks. Null or a string can crash typed clients. The customer exists, so 404 would be misleading.

18. A slash at the end

GET /orders returns 200 but GET /orders/ returns 404. What should a tester do?

  1. A.Ignore it, since nobody adds a trailing slash
  2. B.Raise it, and agree how the API handles trailing slashes
  3. C.Report a server crash of high severity
  4. D.Change every test to add a slash
Show answer

Answer: B. Raise it, and agree how the API handles trailing slashes

Clients and tools sometimes add a trailing slash. The API should either treat both forms the same or redirect clearly. It is a small but real consistency issue to agree and document.

19. API or UI test

You need to verify 40 tax calculation rules. Where is the best place to automate them?

  1. A.Through the UI, filling the checkout form 40 times
  2. B.Manually before every release
  3. C.Only in production monitoring
  4. D.At the API or unit level, sending inputs and checking the calculated tax directly
Show answer

Answer: D. At the API or unit level, sending inputs and checking the calculated tax directly

Business rules with many combinations are best tested below the UI: it is much faster and more stable. A few UI tests can then check that the tax is shown correctly on screen.

20. Status code for a created resource

A POST /users request successfully creates a new user. Which status code should a well-designed REST API usually return?

  1. A.200 OK
  2. B.204 No Content
  3. C.302 Found
  4. D.201 Created
Show answer

Answer: D. 201 Created

201 Created signals that a new resource exists, often with a Location header pointing to it. Asserting the exact status code in API tests catches subtle contract changes that a simple "is it 2xx" check would miss.

API Testing intermediate interview questions medium

21. Chaining requests in Postman

Your login request returns a JSON body with a token field. What is the cleanest way to use that token in the next requests of a Postman collection?

  1. A.Copy and paste the token into every request by hand
  2. B.In the login request's post-response script, run pm.environment.set("token", pm.response.json().token) and use {{token}} in the Authorization header
  3. C.Hard-code a token that never expires in the backend
  4. D.Turn off authentication in the test environment
Show answer

Answer: B. In the login request's post-response script, run pm.environment.set("token", pm.response.json().token) and use {{token}} in the Authorization header

Post-response scripts can read the response and store values in environment or collection variables. Later requests reference them with double curly braces, so the collection runs end to end in the Collection Runner or Newman in CI without manual steps.

22. PATCH or PUT

A user resource has name, email and phone. You send PUT /users/7 with only {"name":"Asha"}. Under strict REST rules, what could happen to email and phone?

  1. A.They may be cleared, since PUT replaces the whole resource
  2. B.They stay the same, since PUT only changes sent fields
  3. C.The request always fails with 405
  4. D.They are copied into the name field
Show answer

Answer: A. They may be cleared, since PUT replaces the whole resource

PUT means "replace the resource with this", so missing fields may be reset. PATCH applies a partial update. Tests should check what the API really does, as clearing data by mistake is a serious bug.

23. Deleting the same item twice

DELETE /coupons/9 returns 204. You send it again and get 404. Is DELETE still idempotent?

  1. A.Yes; the server state is the same after both calls
  2. B.No; the second response code is different
  3. C.No; idempotent methods must return 200 always
  4. D.Yes, but only if the second call returns 204
Show answer

Answer: A. Yes; the server state is the same after both calls

Idempotency is about the effect on the server, not the status code. After one or many deletes, coupon 9 is gone. Returning 404 or 204 on the repeat are both acceptable; what matters is no extra side effects.

24. Stopping a lost update

Two admins edit product 3. Each sends PUT with If-Match: "v7", the ETag they read. The first succeeds. What should the second get?

  1. A.200 OK, overwriting the first change
  2. B.304 Not Modified
  3. C.412 Precondition Failed
  4. D.404 Not Found
Show answer

Answer: C. 412 Precondition Failed

After the first update, the ETag changes, so the second If-Match no longer matches. The server returns 412 and the second admin must reload. This optimistic locking prevents silent lost updates.

25. Pre-request scripts

An API needs a fresh timestamp and an HMAC signature header on every call. Where in Postman do you compute them?

  1. A.In the test script after the response
  2. B.In the collection description field
  3. C.In the environment's initial values
  4. D.In a pre-request script that sets variables
Show answer

Answer: D. In a pre-request script that sets variables

Pre-request scripts run before the request is sent, so they can build values like timestamps, nonces and signatures and store them in variables. Test scripts run after the response arrives, too late for this.

26. Running Postman with a data file

You run a collection with a CSV of 20 rows using the Collection Runner. How does a test script read the "expectedStatus" column for the current row?

  1. A.pm.environment.get("expectedStatus")
  2. B.pm.csv.row("expectedStatus")
  3. C.pm.globals.read("expectedStatus")
  4. D.pm.iterationData.get("expectedStatus")
Show answer

Answer: D. pm.iterationData.get("expectedStatus")

With a data file, each row is one iteration, and pm.iterationData gives that row's values. In requests you can also use {{expectedStatus}}. Data variables take priority over environment variables with the same name.

27. Failing the build on test failures

Newman runs in a CI job. Two Postman assertions fail. What makes the CI job fail too?

  1. A.Newman deletes the build artefacts
  2. B.Newman emails the team and pauses the job
  3. C.Newman exits with a non-zero code when tests fail
  4. D.Newman always exits with code 0
Show answer

Answer: C. Newman exits with a non-zero code when tests fail

Newman returns a non-zero exit code when any assertion or request fails, and CI tools mark a step failed on a non-zero exit. Reporters like JUnit or HTML give details in the build page.

28. Checking a list in REST Assured

The response is {"orders":[{"id":1,"status":"PAID"},{"id":2,"status":"PENDING"}]}. Which check confirms one of the orders is PAID?

  1. A.body("orders.status", hasItem("PAID"))
  2. B.body("orders.status", equalTo("PAID"))
  3. C.body("orders[status]", contains("PAID"))
  4. D.body("status.orders", is("PAID"))
Show answer

Answer: A. body("orders.status", hasItem("PAID"))

In GPath, "orders.status" collects the status of every order into a list: ["PAID","PENDING"]. hasItem checks that the list contains "PAID". equalTo would compare the whole list to one string and fail.

29. Schema checks in REST Assured

How do you check a response against a JSON schema file in REST Assured?

  1. A.body("schema", equalTo("order.json"))
  2. B.contentType("order.json")
  3. C.statusCode(matchesSchema("order.json"))
  4. D.body(matchesJsonSchemaInClasspath("order.json"))
Show answer

Answer: D. body(matchesJsonSchemaInClasspath("order.json"))

The json-schema-validator module gives matchesJsonSchemaInClasspath, which loads a schema from the test resources and checks the whole body. It catches type changes and missing required fields in one assertion.

30. Changing the order in a run

In the Collection Runner, after "Check status" you want to jump back to "Poll job" until the job is done. What does this?

  1. A.pm.execution.setNextRequest("Poll job")
  2. B.pm.environment.set("next", "Poll job")
  3. C.pm.test("Poll job", () => true)
  4. D.pm.request.url = "Poll job"
Show answer

Answer: A. pm.execution.setNextRequest("Poll job")

setNextRequest changes which request runs next in a collection run, which allows loops and skips. It only works in the runner or Newman. Add a retry limit so a stuck job does not loop forever.

31. Path parameters in REST Assured

Which REST Assured call sends GET /orders/77 using a path parameter?

  1. A.given().pathParam("id", 77).when().get("/orders/{id}")
  2. B.given().queryParam("id", 77).when().get("/orders")
  3. C.given().body("id=77").when().get("/orders")
  4. D.given().header("id", 77).when().get("/orders")
Show answer

Answer: A. given().pathParam("id", 77).when().get("/orders/{id}")

pathParam fills a {placeholder} in the path, giving /orders/77. queryParam would give /orders?id=77, a different request. Using named params also handles URL encoding for you.

32. A stub that changes over time

You need a stubbed job API to return "PENDING" on the first two calls and "DONE" on the third. Which WireMock feature fits?

  1. A.Response templating with a random value
  2. B.Proxying all calls to the real API
  3. C.Scenarios with states that change after each match
  4. D.A fixed delay of three seconds
Show answer

Answer: C. Scenarios with states that change after each match

WireMock scenarios let a stub depend on a state, and each match can move the state on. This models flows like polling, retries and step-by-step workflows in a repeatable way.

33. Testing a file upload API

POST /documents takes a file and a "type" field. Which request format is normally used?

  1. A.multipart/form-data with a file part and a text part
  2. B.application/json with the file path as text
  3. C.text/plain with the file pasted in
  4. D.A GET request with the file in the URL
Show answer

Answer: A. multipart/form-data with a file part and a text part

multipart/form-data sends files and fields in one body, each part with its own headers. Postman's form-data body and REST Assured's multiPart() build it. Tests should also cover wrong file types and empty files.

34. Error messages in Arabic

An API returns error messages in English or Arabic. How should a test ask for Arabic?

  1. A.Send Content-Type: text/arabic
  2. B.Add ?lang=right-to-left to the URL
  3. C.Send Accept: application/arabic
  4. D.Send Accept-Language: ar
Show answer

Answer: D. Send Accept-Language: ar

Accept-Language is the standard header for preferred languages. Tests should check the Arabic text, a fallback when the language is not supported, and that error codes stay the same in every language.

35. Null field or no field

The spec says "discount" is optional. Sometimes the API returns "discount": null and sometimes leaves it out. Why should the contract say which?

  1. A.JSON does not allow null values in objects
  2. B.Missing fields make the responses much slower
  3. C.Clients may treat null and missing differently and crash
  4. D.Null values are always a security risk in APIs
Show answer

Answer: C. Clients may treat null and missing differently and crash

Some client code checks for the key, other code for null, and typed clients may fail on one form. In OpenAPI, required and nullable are separate settings. Tests should check the API is consistent with the contract.

36. Which errors to retry

A client library retries failed API calls. Which behaviour should tests confirm?

  1. A.It retries every error up to 10 times
  2. B.It retries 503 and timeouts, but not 400 or 422
  3. C.It never retries any failed request
  4. D.It retries 400 errors until they succeed
Show answer

Answer: B. It retries 503 and timeouts, but not 400 or 422

Temporary failures, like 503, 429 or timeouts, may succeed later and are worth retrying with backoff. Client errors like 400 will fail the same way every time. Retrying non-idempotent calls also needs idempotency keys.

37. Sorting by a field that does not exist

GET /products?sort=price works. What should happen with GET /products?sort=passwordHash or sort=foo;DROP?

  1. A.400 with a list of allowed sort fields
  2. B.200 sorted by passwordHash
  3. C.500 from the database layer
  4. D.200 with the sort silently applied
Show answer

Answer: A. 400 with a list of allowed sort fields

Sort and filter parameters often go into queries, so they must be checked against an allow-list. Sorting by a hidden field can leak data through ordering, and raw values can lead to injection. A clear 400 is the safe result.

38. Compressed responses

A large list endpoint feels slow on mobile. You send Accept-Encoding: gzip. Which header in the response shows compression was used?

  1. A.Transfer-Encoding: zip
  2. B.Content-Type: application/gzip
  3. C.Accept-Ranges: gzip
  4. D.Content-Encoding: gzip
Show answer

Answer: D. Content-Encoding: gzip

When the server compresses a body, it sets Content-Encoding (for example gzip or br). Tests can check that big JSON responses are compressed when the client allows it, which can cut transfer size a lot.

39. Testing the limit parameter

GET /items?limit=N allows 1 to 100. Which set tests its boundaries?

  1. A.limit=0, 1, 100 and 101
  2. B.limit=10, 20 and 50
  3. C.limit=1 only
  4. D.limit=-100 and 1000
Show answer

Answer: A. limit=0, 1, 100 and 101

Test both edges and just outside them: 0 and 101 should be rejected or clamped as documented, and 1 and 100 should work. Also try a missing limit to check the default and a non-number like "abc".

40. A slow report endpoint

A report API sometimes takes 40 seconds, but the mobile app times out at 30 seconds. What should API tests check?

  1. A.Only fast requests, as slow ones are rare
  2. B.That the app retries every second
  3. C.Slow cases, and whether a job-style API is needed
  4. D.That the server timeout is set to 5 seconds
Show answer

Answer: C. Slow cases, and whether a job-style API is needed

Calls slower than the client timeout fail for users even when the server finishes. Tests should measure slow cases with real data sizes. Long work is often better as an async job (202 plus polling).

API Testing interview questions for experienced candidates hard

41. Double charge bug

Some customers are charged twice. It happens only rarely and only on slow networks. What is the most likely cause to test for?

  1. A.A wrong CSS colour on the pay button
  2. B.The database has too many indexes
  3. C.The UI text is not translated
  4. D.A double submit or client retry is processed twice because the payment API is not idempotent
Show answer

Answer: D. A double submit or client retry is processed twice because the payment API is not idempotent

On slow networks users tap again or clients retry, sending the same payment twice. Without an idempotency key or disabled button and server-side duplicate check, both requests succeed. Test by throttling the network, double-clicking and replaying requests.

42. Reusing an idempotency key

A payments API supports an Idempotency-Key header. You send POST /payments with key abc-123 and amount 100, which succeeds. You then send the same key with amount 500. What is the correct behaviour?

  1. A.Charge 500 as a new payment
  2. B.Charge 400 more so the total is 500
  3. C.Reject the second request with an error (for example 409 or 422) because the key was already used with a different body, and create no new charge
  4. D.Return 500 Internal Server Error
Show answer

Answer: C. Reject the second request with an error (for example 409 or 422) because the key was already used with a different body, and create no new charge

An idempotency key means "this is the same operation". Repeating it with the same body should return the original result without charging again. Reusing it with a different body is a client error and must be rejected, otherwise retries can create wrong charges. Also test concurrent requests with the same key and key expiry.

43. equalTo fails on a decimal

The response is {"price": 10.5}. This REST Assured check fails with a message saying 10.5 is not 10.5. Why?

  1. A.REST Assured cannot read decimal numbers at all
  2. B.JsonPath returns a Float by default; the check uses a Double
  3. C.The price field is sent as a string
  4. D.Hamcrest equalTo only works on text
Show answer

Answer: B. JsonPath returns a Float by default; the check uses a Double

By default REST Assured parses JSON decimals as Float, so equalTo(10.5) (a Double) does not match. Use equalTo(10.5f), or set JsonConfig to return BigDecimal and compare with a BigDecimal, which is also better for money.

44. Who writes a Pact contract

In consumer-driven contract testing with Pact, how is the contract created and checked?

  1. A.The provider writes it, then every consumer verifies it
  2. B.A tester writes it by hand in a shared spreadsheet
  3. C.Consumer tests generate it; the provider verifies against it
  4. D.It is generated from production logs every night
Show answer

Answer: C. Consumer tests generate it; the provider verifies against it

The consumer's tests run against a Pact mock and record the requests and responses they need into a pact file. The provider then replays those requests against its real code to verify. A broker shares pacts and results.

45. Exact values in a pact

A consumer pact expects "createdAt": "2026-03-01T10:00:00Z" exactly. Provider verification keeps failing because real timestamps differ. What is the right fix?

  1. A.Ask the provider to hard-code that timestamp
  2. B.Use a type or regex matcher for the timestamp
  3. C.Delete the createdAt field from the pact
  4. D.Turn off provider verification for this pact
Show answer

Answer: B. Use a type or regex matcher for the timestamp

Contracts should pin the shape and type the consumer relies on, not incidental values. Pact matchers like like(), regex or a datetime matcher check the field is a valid timestamp without fixing its value.

46. Webhooks twice and out of order

A provider may send the same webhook more than once and not always in order. Which test is most important?

  1. A.Send each event once, in the right order, and check 200
  2. B.Send an event with an empty body and expect a 400
  3. C.Send 1,000 events per second and measure the speed
  4. D.Send "paid" twice and "created" after "paid"; check final state
Show answer

Answer: D. Send "paid" twice and "created" after "paid"; check final state

Most webhook systems deliver at least once and do not guarantee order. Handlers must be idempotent (use the event ID) and must not let an older event overwrite a newer state. Testing only perfect delivery misses both bugs.

47. Testing a 202 Accepted API

POST /reports returns 202 with a Location of /reports/jobs/31. How should an automated test check the report?

  1. A.Assert the report content in the 202 response
  2. B.Sleep a fixed 60 seconds, then fail if not done
  3. C.Treat 202 as a failure, since it is not 200
  4. D.Poll the job URL until done or timeout, then check it
Show answer

Answer: D. Poll the job URL until done or timeout, then check it

202 means the work was accepted but is not finished. The test should poll the status URL with a sensible interval and overall timeout, then check the final result. Fixed sleeps are slow and still flaky.

48. Too much data in a response

GET /users/me returns the profile plus "passwordHash", "isAdmin" and "internalNotes". The UI only shows the name and email. Why is this a defect?

  1. A.The API exposes sensitive fields the client does not need
  2. B.The UI is too slow to show all of those fields
  3. C.The response should have been sent as XML instead
  4. D.The user should be shown their own password hash
Show answer

Answer: A. The API exposes sensitive fields the client does not need

Hiding fields in the UI is not protection; anyone can read the raw response. OWASP's API Security Top 10 covers this under object property level authorisation. Tests should check responses contain only allowed fields.

49. Static settings and parallel tests

Tests set RestAssured.baseURI in their own setup, some to the orders service and some to the users service. Run in parallel, tests sometimes hit the wrong service. Why?

  1. A.REST Assured cannot send two requests at once
  2. B.Parallel tests always use the last URL in the file
  3. C.JUnit resets baseURI between every test
  4. D.RestAssured.baseURI is a global static shared by threads
Show answer

Answer: D. RestAssured.baseURI is a global static shared by threads

Static fields like RestAssured.baseURI are shared across all threads. One test changes it while another is running. Use a RequestSpecification per test or per client instead of global settings when running in parallel.

50. Machine-to-machine auth

Your test suite calls a backend API as a service, with no user logging in. Which OAuth 2.0 grant fits?

  1. A.Authorization code with PKCE
  2. B.Implicit grant
  3. C.Client credentials
  4. D.Device authorization
Show answer

Answer: C. Client credentials

The client credentials grant lets a service swap its client ID and secret for a token, with no user involved. Authorization code with PKCE is for user logins in apps. The implicit grant is deprecated in current OAuth guidance.

51. Testing a token right at expiry

An API accepts JWTs and allows 30 seconds of clock skew. A token's exp is 10:00:00. Which tests check the expiry handling?

  1. A.One call at 09:00 accepted, and nothing near 10:00
  2. B.Calls at 10:00:20 accepted, at 10:00:40 rejected with 401
  3. C.Calls at 10:00:20 and 11:00 both accepted with 200
  4. D.Calls at 09:59:50 rejected, at 10:00:40 accepted
Show answer

Answer: B. Calls at 10:00:20 accepted, at 10:00:40 rejected with 401

With a 30-second leeway, a token is still valid until 10:00:30. Testing just inside and just outside that window catches wrong leeway or ignored exp claims. An expired token should get 401.

52. Error message shows code details

A malformed request returns 500 with a full Java stack trace, SQL query and library versions in the body. Why is this a security bug?

  1. A.It gives attackers internal details to plan attacks
  2. B.Stack traces make every response much slower
  3. C.Clients cannot parse such long error bodies
  4. D.It breaks the API's documented JSON schema
Show answer

Answer: A. It gives attackers internal details to plan attacks

Detailed errors reveal frameworks, versions, table names and code paths that help attackers. Production APIs should return a generic message with an error ID and keep details in server logs. Fuzzing bad input often finds this.

53. Same URL, different method

GET /admin/users/5 correctly returns 403 for a normal user. What extra test checks for method-based access bugs?

  1. A.Send GET again with a much longer timeout
  2. B.Send GET to /admin/users/6 as an admin
  3. C.Send OPTIONS and expect a 200 with a body
  4. D.Send DELETE and PUT to the same URL as a normal user
Show answer

Answer: D. Send DELETE and PUT to the same URL as a normal user

Access rules are sometimes set per method and one gets missed, so DELETE may work where GET is blocked. Trying every method on protected URLs with low-privilege tokens finds these gaps.

54. GraphQL introspection in production

In a production GraphQL API that serves only your own apps, the __schema introspection query returns the full schema, including admin mutations. What should a tester report?

  1. A.Introspection makes queries slower for everyone
  2. B.Introspection exposes the whole schema to attackers
  3. C.Introspection is needed by all production clients
  4. D.Admin mutations cannot be called if listed
Show answer

Answer: B. Introspection exposes the whole schema to attackers

Introspection is useful in development, but in a private production API it hands attackers a map of every type and mutation. Many teams turn it off or limit it there. Hiding the schema is not access control, so mutations still need auth checks.

55. One GraphQL query, many DB calls

A GraphQL query for 50 orders with their customers makes 51 database calls. What is this problem called, and how do you test for it?

  1. A.The N+1 problem; count DB queries per request
  2. B.A cache miss; clear the cache and retry
  3. C.A race condition; run the query twice
  4. D.A timeout; raise the request timeout
Show answer

Answer: A. The N+1 problem; count DB queries per request

Resolving each customer separately causes 1 query for orders plus 1 per order. Batching with a DataLoader fixes it. Tests can count database queries for a request, or watch latency grow with the list size.

56. Checking a provider against its spec

A provider has no Pact consumers but publishes an OpenAPI spec. What kind of check verifies the running service matches the spec?

  1. A.Compare the spec file with last month's copy
  2. B.Ask consumers to read the spec carefully
  3. C.Count the number of endpoints in the spec
  4. D.Generate requests from the spec and validate responses
Show answer

Answer: D. Generate requests from the spec and validate responses

Tools like Schemathesis or Dredd read the OpenAPI spec, send requests and check status codes and bodies match the schema. This provider-driven contract testing catches drift between docs and code.

57. One coupon used twice

A coupon is valid for one use per user. A tester sends 10 identical redeem requests at the same moment and 3 succeed. What does this show?

  1. A.The coupon limit was set to 3 by mistake
  2. B.The client sent requests to different servers
  3. C.Normal behaviour for any API under load
  4. D.A race condition: check-then-update is not atomic
Show answer

Answer: D. A race condition: check-then-update is not atomic

Each request checked "not used yet" before any of them marked it used. The fix is an atomic update or a unique constraint. Parallel requests are the only way to find such bugs; serial tests always pass.

58. Breaking changes between services

Team A's service often breaks Team B's client when it changes its API. Full end-to-end tests are slow and flaky. Which approach fits best?

  1. A.Consumer-driven contract testing (for example Pact), where the provider verifies the consumer's expectations in its own CI
  2. B.More UI tests that go through both services
  3. C.Manual testing by Team B before every Team A release
  4. D.Freezing Team A's API forever
Show answer

Answer: A. Consumer-driven contract testing (for example Pact), where the provider verifies the consumer's expectations in its own CI

Contract tests record what a consumer needs from a provider and verify it against the provider on every change, without deploying the whole system. They catch breaking changes early and fast, complementing a small number of E2E tests.

59. Can I deploy this service

You use Pact with a broker. The provider team wants to know if their new version is safe to release to production. What answers this?

  1. A.Running the provider's unit tests
  2. B.A manual check of the API docs
  3. C.Running all end-to-end tests in staging
  4. D.The can-i-deploy check, which looks up whether this version has verified the contracts of the consumer versions currently in production
Show answer

Answer: D. The can-i-deploy check, which looks up whether this version has verified the contracts of the consumer versions currently in production

The broker stores contracts and verification results for each version and environment. can-i-deploy turns that into a yes/no gate in the pipeline, giving fast safety without a full integrated environment.

60. A fake that drifted from reality

Unit tests use a FakePaymentGateway. Over time it accepts amounts the real gateway rejects, and bugs reach production. What practice keeps fakes honest?

  1. A.Delete the fake and call the real gateway sandbox from every unit test
  2. B.Run one shared contract test suite against both the fake and the real gateway sandbox
  3. C.Let each developer update the fake whenever they think it is wrong
  4. D.Make the fake accept every input so that unit tests never fail on it
Show answer

Answer: B. Run one shared contract test suite against both the fake and the real gateway sandbox

If the same behavioural tests run against the fake and the real implementation (or its sandbox), any difference shows up as a failing test. The fake then stays a faithful, fast substitute, and unit tests remain trustworthy.

Ready to test yourself?

Take a 15-question API Testing MCQ test with a score at the end, or practise the full API Testing question bank and earn points on the leaderboard.

Start the API Testing testTake a mock interview