Interview Insights · API Testing
Why APIs Eliminates More Candidates Than They Expect
Quick summary — API round
The API round eliminates candidates not with hard theory, but with simple workflows they never practised end to end. When I give a live API task, it is rarely complicated. Create a resource, fetch it, update it, try to break it. Many candidates can send each request on its own, but they cannot pass an ID from one call to the next, they never test invalid input, and they check one field instead of the response structure. In Uncodemy mock rounds, these are the exact points where practice changes the result fastest.
In this guide you will learn:
- Why single-request skill is not enough for an API round
- How to chain requests with variables in Postman
- Negative test cases interviewers expect you to suggest
- JSON schema validation and why it beats single-field checks
- A practice workflow that covers all four layers
SECTION 01Chaining requests: the first silent filter
Real API tests are rarely one call. You log in to get a token, create an order to get its ID, then fetch, update or cancel that order. If you have only ever tested endpoints in isolation, you will copy values by hand from one response into the next request. In a live round, that looks slow and fragile, and the interviewer will ask how you would automate it.
The skill is simple once practised: extract a value from a response, store it in a variable, and reference that variable in later requests. Every API tool supports this.
| Chain step | What you extract | Where you store it | Used in |
|---|---|---|---|
| Login | access_token from the body | Collection or environment variable | Authorization header of every later call |
| Create order (POST) | id of the new order | Environment variable orderId | GET, PATCH and DELETE URLs |
| Fetch order (GET) | status and total | Local variables in the test | Assertions comparing with what was sent |
| Cancel order (DELETE) | Nothing; check status code | Not needed | Final GET should return 404 or cancelled status |
// Tests tab of: POST {{baseUrl}}/orders
pm.test("Order created", function () {
pm.response.to.have.status(201);
});
const body = pm.response.json();
pm.test("Response has an order id", function () {
pm.expect(body.id).to.be.a("number");
});
// Save for the next requests in the collection
pm.environment.set("orderId", body.id);
pm.environment.set("orderTotal", body.total);// Request: GET {{baseUrl}}/orders/{{orderId}}
// Tests tab:
pm.test("Fetched the same order", function () {
pm.response.to.have.status(200);
const body = pm.response.json();
pm.expect(body.id).to.eql(Number(pm.environment.get("orderId")));
pm.expect(body.total).to.eql(Number(pm.environment.get("orderTotal")));
});
pm.test("New order starts as PLACED", function () {
pm.expect(pm.response.json().status).to.eql("PLACED");
});
The Number() conversion is a small detail that catches people out. Postman environment values are stored as strings, so comparing them directly with a numeric id fails. Explaining that in the interview shows you have actually run chained tests.
SECTION 02Negative testing: the question that ends many rounds
After a candidate gets the happy path working, I usually ask, 'Now how would you try to break it?'. This is where a surprising number of rounds end. Candidates suggest one invalid value, or say they would 'test with wrong data', without naming specific cases or expected responses.
A strong answer lists categories: missing required fields, wrong data types, boundary values, invalid formats, unauthorised access and duplicate submissions. For each, it names the expected status code and error message. That is the API equivalent of thinking like a tester.
| Negative category | Example request | Expected response | Why it matters |
|---|---|---|---|
| Missing required field | POST /orders without productId | 400 with a message naming productId | Clients must know what to fix |
| Wrong data type | qty: "two" instead of 2 | 400 or 422 with a type error | Prevents bad data reaching the database |
| Boundary value | qty: 0 and qty: 101 when the limit is 1-100 | 400 for both, 201 for 1 and 100 | Limits are where bugs hide |
| Access to another user's data | GET /orders/{otherUsersId} | 403 or 404, never the data | Data leaks are serious defects |
// Request: POST {{baseUrl}}/orders
// Body: { "qty": 2 } (productId deliberately missing)
pm.test("Rejected with 400", function () {
pm.response.to.have.status(400);
});
pm.test("Error names the missing field", function () {
const body = pm.response.json();
pm.expect(JSON.stringify(body)).to.include("productId");
});
pm.test("No order id returned", function () {
pm.expect(pm.response.json()).to.not.have.property("id");
});qty,expectedStatus
0,400
1,201
100,201
101,400
-1,400
// Save as qty-boundaries.csv and run the collection with
// the Collection Runner (or Newman with -d), using a body:
// { "productId": 42, "qty": {{qty}} }
// Note: {{qty}} is unquoted so it is sent as a number.
// Tests tab:
pm.test("qty " + pm.iterationData.get("qty") + " handled",
function () {
pm.response.to.have.status(
Number(pm.iterationData.get("expectedStatus")));
});
// Command line:
// newman run orders.postman_collection.json \
// -e test.postman_environment.json -d qty-boundaries.csv
The data-driven version is worth practising. It shows the interviewer that you think in sets of cases rather than one at a time, and it maps cleanly onto boundary value analysis, which they may ask about next.
SECTION 03Schema validation: checking the whole response, not one field
Many candidates assert on one field, often the name or the id, and stop. That misses entire classes of bugs: a field that changes type from number to string, a required field that disappears, or an unexpected null. Frontend and mobile apps break on exactly these changes.
Schema validation checks the structure of the whole response at once. You describe which fields exist, their types and which are required, and the test fails if the response does not match. It is one of the clearest signs that a candidate has worked on real API suites.
| Bug type | Single-field check catches it? | Schema check catches it? | Real-world effect |
|---|---|---|---|
| total changes from number to string | Only if you assert on total | Yes, type mismatch | App calculations break or show NaN |
| Required field missing | Only if it is the field you check | Yes, required list | Screen shows blank or crashes |
| Unexpected null value | Rarely | Yes, if type excludes null | Null errors in client code |
| Extra field added | No | Only if additionalProperties is false | Usually harmless, sometimes a data leak |
{
"type": "object",
"required": ["id", "productId", "qty", "total", "status"],
"properties": {
"id": { "type": "integer" },
"productId": { "type": "integer" },
"qty": { "type": "integer", "minimum": 1, "maximum": 100 },
"total": { "type": "number", "minimum": 0 },
"status": { "type": "string",
"enum": ["PLACED", "SHIPPED", "CANCELLED"] },
"couponCode":{ "type": ["string", "null"] }
},
"additionalProperties": false
}// Tests tab of: GET {{baseUrl}}/orders/{{orderId}}
const orderSchema = {
type: "object",
required: ["id", "productId", "qty", "total", "status"],
properties: {
id: { type: "integer" },
productId: { type: "integer" },
qty: { type: "integer", minimum: 1, maximum: 100 },
total: { type: "number", minimum: 0 },
status: { type: "string",
enum: ["PLACED", "SHIPPED", "CANCELLED"] },
couponCode:{ type: ["string", "null"] }
},
additionalProperties: false
};
pm.test("Order matches schema", function () {
pm.response.to.have.jsonSchema(orderSchema);
});
Be ready to explain why couponCode allows null while total does not. Choices like that come from the API contract, and talking about them shows you read the contract instead of guessing.
SECTION 04One practice workflow that covers all four layers
Build this small collection once against any practice API that supports create, read, update and delete. Then run it, break it and explain it aloud. If you can do all three tabs comfortably, you are ready for most live API tasks.
FOLDER 1: Auth
01 POST /login -> save token
FOLDER 2: Happy path chain
02 POST /orders -> save orderId, total
03 GET /orders/{{orderId}} -> compare, schema check
04 PATCH /orders/{{orderId}} (qty: 3)
05 GET /orders/{{orderId}} -> qty is 3, total updated
06 DELETE /orders/{{orderId}}
07 GET /orders/{{orderId}} -> 404 or CANCELLED
FOLDER 3: Negative
08 POST /orders, missing productId -> 400
09 POST /orders, qty as string -> 400/422
10 GET /orders/1 with no token -> 401
11 Boundary run with CSV -> mixed# Install Newman (Postman's command-line runner)
npm install -g newman newman-reporter-htmlextra
# Run with an environment and an HTML report
newman run orders.postman_collection.json \
-e test.postman_environment.json \
-r cli,htmlextra \
--reporter-htmlextra-export reports/orders.html
# Exit code is non-zero if any test fails,
# so a CI job (Jenkins, GitHub Actions, GitLab CI)
# marks the build as failed automatically.
# Keep secrets out of the exported environment file;
# pass them with --env-var "password=$API_PASSWORD"Practise this two-minute explanation:
"My collection has three folders. Auth logs in and
saves the token. The happy path creates an order,
saves its ID and reuses it to fetch, update and delete,
checking the schema on each GET.
The negative folder covers a missing field, a wrong
type, no token, and boundary values for quantity from
a CSV file.
It runs in CI with Newman, and the build fails if any
test fails. Secrets come from CI variables."
In Uncodemy mock rounds, this is usually followed by:
'What would you add next?' Have one answer ready.
SECTION 05Habits that keep you out of the elimination zone
These habits come from watching where candidates most often stall in live API tasks.
- Never copy values by hand — Even in practice, store tokens and IDs in variables. The habit will show automatically in a live task.
- Ask for the API contract — In a live task, ask whether there is documentation or a schema. It is a professional first move, and it tells you what to assert.
- Suggest negatives before being asked — Once the happy path works, say 'now let me try a few ways to break it'. It shows initiative and tester instinct.
- Check state after writes — After POST, PATCH or DELETE, do a GET to confirm the change really happened. A 200 alone does not prove it.
- Keep each test small — One clear assertion group per test makes failures easy to read, which interviewers notice when they look at your output.
SECTION 06Interview Q&A — API round
Q1How do you chain API requests in Postman?
I extract the needed value in the Tests script of one request, for example pm.environment.set('orderId', pm.response.json().id), and then reference it as {{orderId}} in later URLs, headers or bodies. I run them in order as a collection, locally or with Newman in CI.
Q2What negative test cases would you write for a create-order API?
Missing required fields, wrong data types, boundary values for quantity, invalid product IDs, requests without a token, requests with another user's token, and duplicate submissions. For each I specify the expected status code and that the error message is clear.
Q3What is JSON schema validation and why use it?
It checks the whole response against a definition of required fields, types and allowed values. It catches type changes, missing fields and unexpected nulls that single-field assertions miss, which are common causes of client app failures.
Q4How do you run Postman tests in a CI pipeline?
I export the collection and environment and run them with Newman, Postman's command-line runner. Newman returns a non-zero exit code on failure, so the CI job fails. I add an HTML reporter for readable results and pass secrets as environment variables.
Q5Why check the state with a GET after a POST or PATCH?
A success code only says the server accepted the request. A follow-up GET confirms the data was really stored or changed as expected, and catches bugs where the API returns success but saves the wrong values.
SECTION 07Test yourself — API round quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
What is asked in an API testing interview round?
Expect HTTP methods and status codes, authentication, request chaining, negative test design, schema validation, and often a live task: create, fetch, update and delete a resource with assertions. Some rounds also ask how you run API tests in CI.
How do I practise API testing for interviews?
Use a practice API that supports full create, read, update and delete operations. Build a small collection with a chained happy path, negative cases and schema checks, run it with Newman, and explain it aloud.
What is Newman in Postman?
Newman is Postman's command-line collection runner. It runs exported collections with environments and data files, produces reports, and returns an exit code that CI tools use to pass or fail a build.
What are negative test cases in API testing?
They are tests that send invalid or unexpected input, such as missing fields, wrong types, out-of-range values, invalid tokens or access to other users' data, and check that the API rejects them with the right status and a clear message.
Is JSON schema validation required for API testing?
It is not always required, but it is widely used and very valuable. It checks the full structure and types of responses in one assertion and catches contract-breaking changes early, which is why interviewers often ask about it.
Does Uncodemy help with APIs interview questions?
Yes. Uncodemy's API Automation Testing Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise APIs interview questions with trainer feedback before the real interview. You can book a free demo class from this page to see how the sessions work.
SECTION 09Related reads
Classroom & online · Noida
Pass the API round, not just the first request
Our API Automation Testing Training Course covers Postman, Newman, REST Assured, chaining, negative testing and schema validation through hands-on API projects and live mock tasks.
Talk to a counsellor for current fees- Postman & Newman in CI
- REST Assured automation
- Schema & negative testing
- Live API mock tasks