API Test Case Interview Questions: Boundaries, Idempotency, and Authorization

An API test can return the expected status code and still miss the important failure: a reservation was created twice, a rejected request changed inventory, or one tenant received another tenant's data. In an interview, a long list of inputs is less useful than a short set of cases with precise postconditions.

The core of API test case interview questions is deciding what must remain true before and after a request. Start with the contract, identify the state that matters, and explain how your assertions would catch a plausible implementation mistake.

Evidence boundary: HTTP semantics, Stripe's documented behavior, and OWASP guidance provide the factual anchors below. The reservation service, test matrix, and failure scenarios are original practice exercises. They are not candidate reports or a claim about any employer's actual interview. Try the reasoning alongside Implement CRUD API and tests.

What should you clarify before listing API test cases?

Suppose the prompt is: “Test an endpoint that reserves stock.” Ask for the operation's business contract before choosing a framework. Does creating a reservation immediately reduce available stock? Can reservations expire? Is the caller allowed to choose a tenant? Does a successful response mean the operation committed, or merely that it entered a queue?

For the worked exercise, assume POST /reservations accepts a SKU and an integer quantity from 1 through 5. The authenticated tenant comes from server-validated identity. A successful reservation reduces available stock atomically. The client supplies an idempotency key scoped to that tenant and operation. The service retains completed results for a documented retry window.

These are exercise assumptions, not requirements imposed by HTTP. A different product can choose a different contract. State the assumptions aloud so the interviewer can change them before you build the suite.

A test record should name five things: initial fixture, actor, request, response assertion, and durable-state assertion. “Invalid quantity returns an error” is incomplete. “Quantity zero is rejected, no reservation exists, and available stock remains unchanged” describes a failure that your test can actually detect.

Also establish what the test can observe. A black-box suite may inspect a read endpoint and a test event sink; a service integration test may query a dedicated test database. Avoid claiming an internal invariant is verified when your harness can only see a response body.

Which boundary cases deserve separate tests?

Test values around changes in meaning. For the quantity range, use 0, 1, 5, and 6. Add an omitted quantity, explicit null, a string, and a fractional number because parsing and validation can fail differently. Keep a valid authorized actor and sufficient stock in these tests so another failure does not mask the boundary you meant to exercise.

The following ledger is specific to the reservation contract. Each row begins from a fresh fixture rather than inheriting state from the previous row.

The exact status codes belong in the endpoint specification. Do not confidently choose between every possible validation code when the interviewer has not supplied that policy. State the expected error category, then align the executable assertion with the agreed contract.

Test combinations selectively. Quantity 6 with an expired token does not necessarily prove quantity validation works: authentication may terminate processing first. Start with one changed condition per case. Add combinations when their interaction matters, such as valid syntax plus insufficient stock, or a valid key supplied by the wrong tenant.

Boundary coverage also includes representation. If the contract counts characters, clarify whether that means bytes, Unicode code points, or user-perceived characters. A maximum-length identifier test is only meaningful after the unit is defined.

How do you test idempotency beyond repeating a request?

Official standard: RFC 9110 defines idempotency in terms of the intended server effect of repeated identical requests. It does not require identical response bodies or status codes. PUT and DELETE have idempotent semantics; POST does not acquire them merely because a client retries it.

A POST endpoint can implement a separate idempotency contract. Vendor-specific fact: Stripe documents storing and replaying the first result for an idempotency key after execution begins, including failures, and comparing parameters on reuse. That behavior is a useful reference, not a rule every API follows.

For the reservation exercise, first submit key reserve-17, quantity 2, with stock 10. Then repeat it within the retention window. Assert that both responses identify the same reservation and that stock is 8. Two successful responses with different reservation IDs are a failure even if the suite only expected success codes.

Next change quantity to 3 while keeping the key. Our exercise contract rejects conflicting reuse rather than silently replaying a result for a different request. Verify that stock remains 8. Then submit the original request under a new key: that represents a new operation and may legitimately create another reservation.

Key scope is a separate test. Two tenants using the same literal key must not receive one another's response. Whether they may each create a reservation depends on the documented scope; in this exercise, they can. Test the operation name too if a service accepts keys across multiple endpoints.

Finally, place requests immediately before and after key expiry using a controlled clock. A retention window limits retry protection. Do not write “exactly once forever” when the contract only deduplicates requests for a bounded time.

What happens when the response is lost after commit?

A clean sequential replay is necessary but insufficient. The harder case is uncertainty: the server commits a reservation, but the client times out before receiving the result. If the client retries, the service must recover the recorded outcome without applying the reservation again.

Use a controlled failure point after the business transaction commits and before the response reaches the client. Keep the original key. After retry, check the reservation identity, inventory delta, and any observable downstream event identity. A generic network timeout injected before the request reaches the server does not exercise this failure window.

For concurrent requests, release two workers through a barrier with the same key and payload. The allowed response sequence might be one success plus one retryable “in progress” response, or two responses referencing the completed result. Define that behavior first. The invariant is one committed reservation and one stock deduction, not a particular arrival order.

Use a second concurrency case with distinct keys competing for the last unit. Exactly one reservation should succeed under the exercise's atomic stock rule. The losing request must leave no partial reservation. This tests inventory concurrency rather than key deduplication; combining the two into one case makes diagnosis harder.

A passing run is evidence for that execution, not proof that every schedule is safe. In an interview, explain how repeated stress runs complement a deterministic integration test and how the implementation's transaction or conditional-write design supports the invariant.

How should authorization change your test matrix?

Security-project guidance: OWASP's API1:2023 guidance calls for object-level authorization whenever an endpoint receives an object ID and acts on that object. Possessing a valid login does not establish permission to read or modify a particular reservation.

Create explicit fixtures: Alice and Bob in tenant A, and Carol in tenant B. Give Alice ownership of reservation R1. Define whether Bob's role can read or cancel R1, then test that rule. Do not assume “same tenant” means “same permissions.”

Now keep the request valid while replacing the actor. An unauthenticated caller, an authenticated caller without the required action permission, and a caller from another tenant represent distinct cases. For denied mutations, inspect the postcondition as well as the error: R1 must remain active and stock must remain reserved.

Include object references outside the URL path. A cancellation body, bulk request, or nested resource may carry an ID even when the top-level route looks harmless. For a bulk operation, clarify whether one unauthorized item rejects the entire batch or produces per-item results. Test that contract without leaking inaccessible item details.

Then revoke a permission between two requests. A cached authorization decision may otherwise make the second request pass unexpectedly. Set the expected propagation window explicitly; a test that assumes instantaneous revocation against an eventually updated policy cache may be testing an undocumented promise.

Keep these security cases within an authorized test environment and controlled accounts. The purpose is to establish the service's permission contract with reproducible fixtures.

What should an API assertion verify besides status?

Verify identity, values, and state transitions. A successful reservation response should reference the requested SKU, accepted quantity, correct tenant context where exposed, and a usable reservation ID. A schema assertion can catch a missing field while still accepting the wrong customer's object.

For rejected operations, assert absence of forbidden effects. That may include unchanged inventory, no active reservation, and no success event. If events are asynchronous, define a bounded observation window and an event watermark or correlation ID. An immediate empty queue read does not prove that an event will never arrive.

For successful asynchronous operations, poll a meaningful completion condition until a deadline rather than sleeping for an arbitrary number of seconds. Record the last observed state on failure. The same deadline should not hide indefinite processing by restarting after every unsuccessful poll.

Test cleanup is part of correctness. Give each case unique fixture identifiers and remove only its own data. A failed setup must not leave an old reservation ID available for later steps. Report cleanup failures separately so they do not replace the original assertion error.

If another worker can legitimately change inventory, isolate the SKU or compare a transaction-specific ledger entry. An absolute “stock equals 8” assertion is valid only when the test controls the other writers.

Which cases should you prioritize with ten minutes left?

Start with one successful operation and its durable postcondition. Add one invalid boundary, one denied actor, one same-key replay, and one post-commit timeout. These cover different failure mechanisms. Explain what remains untested: concurrency, retention expiry, bulk authorization, and asynchronous event behavior.

Prioritization depends on the operation. A read-only catalog endpoint may deserve more attention to filtering, pagination stability, and information leakage. A reservation endpoint puts duplicate effects and overselling near the top. Do not copy a payment checklist into every API without connecting each case to a business risk.

A concise answer can sound like this: “I will first agree on the reservation contract. Then I will test valid and invalid boundaries in isolation, verify permission changes with separate actors, and retry across the commit boundary. Each mutation case checks both the response and the resulting reservation and inventory state.”

Five PracHub exercises for stronger API test reasoning

Use these as adjacent practice prompts, not evidence that an employer asks the exact reservation exercise above. Write one initial fixture and one durable postcondition before solving each.

Start with Implement CRUD API and tests, then add the timeout case. Your explanation should make it clear which implementation mistake each assertion would expose.

Sources and Further Reading

• RFC 9110: HTTP idempotent methods
• Stripe: Idempotent requests
• OWASP API Security: Broken Object Level Authorization