API Testing Real Scenarios

The most common trap junior QA engineers fall into during technical interviews is defining API testing simply as "Checking if the endpoint returns a 200 Status Code."

In real-world distributed architectures, a 200 OK is completely meaningless if the underlying database transaction rolled back, the cache wasn't invalidated, or the payload exposed PII (Personally Identifiable Information).

If you want to pass senior SDET and QA automation interviews, you must demonstrate that you test the entire system boundary, not just the HTTP layer. Here are the real scenarios you must validate.

Scenario 1: State Management Validation

An API is often just a window into a database. You must verify the state changed.

The Workflow:

1. A user calls POST /api/ecommerce/cart/checkout with a valid payload.
2. The endpoint returns 201 Created with an order_id.

The Beginner Test: Just asserted response.status_code == 201.

The Senior Test (What you should say in interviews):

1. Extract the order_id from the API response.
2. Query the database using the framework's DB client (SELECT status FROM orders WHERE id=...). Does the DB actually reflect the CREATED status?
3. Query the Inventory REST API. Did the stock count decrease by the exact amount purchased?
4. Call GET /api/ecommerce/orders/{order_id}. Does the read endpoint return the exact same JSON schema and values that the POST endpoint generated?

Scenario 2: Idempotency Validation

Network connections drop. Clients click "Submit" twice. If an API handles financial transactions or side-effects, it must be Idempotent (calling it twice has the exact same safe effect as calling it once).

The Workflow: You are testing a refund endpoint: POST /api/payments/refund with a unique transaction_id and a refund amount.

The Senior Test:

1. Send the POST request. Validate the 200 OK and that the refund is processed in the database.
2. Send the exact same request again immediately.
3. The API should return 200 OK or 409 Conflict, but under no circumstances should the user be refunded a second time.
4. Verify the database shows only 1 refund processed.

When you mention testing for Idempotence keys (x-idempotency-key headers) in an interview, the hiring manager immediately knows you understand production-grade system design.

Scenario 3: Pagination and Sorting Boundaries

Any API returning lists of data implements pagination (Offset or Cursor-based). This is notoriously buggy.

The Workflow: An endpoint GET /api/users accepts ?limit=10&page=2&sort=created_at,desc.

The Senior Test: Don't just check if a list comes back. Test the boundaries.

1. Mathematical boundary: If the database has 25 total users, page 1 with limit=10 should return 10 users. Page 2 should return 10. Page 3 should return exactly 5. Page 4 should return an empty array [], not a 404 or 500.
2. Sorting validation: Iterate through the JSON response using your automation script and physically compare the timestamps. Does users[0].created_at actually parse to a date mathematically greater than users[1].created_at?
3. Cursor hijacking: If it's Cursor-based pagination, try passing invalid Base64 cursor strings. Does the API elegantly handle it with a 400 Bad Request, or does it crash?

Scenario 4: Authorization and Scope Bleed (BOLA)

Broken Object Level Authorization (BOLA), formerly IDOR, is the #1 API vulnerability globally. QA must test it.

The Workflow: User A logs in, gets a JWT token, and accesses their profile via GET /api/users/profile/123.

The Senior Test:

1. Log in as User A to get their JWT token in the automation setup.
2. Call an endpoint meant for a different user, e.g., GET /api/users/profile/999, but pass User A's token.
3. It must return a 403 Forbidden or 404 Not Found. If it returns a 200 OK with User 999's data, your company has a critical vulnerability.
4. Automate this exact flow for every single PUT, DELETE, and GET endpoint in the system.

Final Takeaway

To excel in API testing, you must think like an engineer trying to break the system logic, not a user following a happy path. In your next interview, bring up Idempotency, Database State Validation, and BOLA, and you will set yourself apart from 90% of candidates.

Ready to level up your automation setup? Check out our QA products for pre-built Postman collections and Pytest frameworks focused on these exact edge cases.