#1 India's Top IT Training Institute

×

About Uncodemy

Know more about who we are and what we stand for.

About Us

About Us

Discover our mission to equip individuals with essential IT skills and industry expertise.

Read More →
UnCodeMy Gallery

UnCodeMy Gallery

Explore highlights from our IT training sessions and success stories.

Read More →
×

Free Resources

Learn, practice and plan your career — bilkul free.

Tutorials

Tutorials

Step-by-step written tutorials to learn any technology at your own pace.

Read More →
Free Counselling

Free Counselling

Book a free video counselling session and pick the right course for you.

Read More →
Online Compiler

Online Compiler

Write, run and test your code online — no setup required.

Read More →

Interview Insights · API Testing

Why APIs Eliminates More Candidates Than They Expect

Candidates often treat the API section as the easy part of a testing interview. Send a request, check a 200, done. That belief is exactly why so many are eliminated there. The round tests workflows, not single requests.

Tracks
Where Candidates Drop · Live Interactive
Task given
—
What the panel asks for
Common attempt
—
What most candidates do
What was wanted
—
What would have passed
Request→Chain→Negative→Schema
Click a task to see where candidates are commonly eliminated in an API round, and what the interviewer was hoping to see instead.

Home / Tutorials / Career Guides / Why APIs Eliminates More Candidates Than They Expect

Interview Insights · API Testing

Why APIs Eliminates More Candidates Than They Expect

LAYER 1LAYER 2LAYER 3LAYER 4Single callSend requestCheck statusEasyChainingPass ID from onecall to the nextFilterNegativeBad input, authmissing fieldsFilterContractSchema, typesand headersFilter
An API round usually climbs four layers. Many candidates are comfortable with the first and are eliminated somewhere in the next three.

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:

  1. Why single-request skill is not enough for an API round
  2. How to chain requests with variables in Postman
  3. Negative test cases interviewers expect you to suggest
  4. JSON schema validation and why it beats single-field checks
  5. 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 stepWhat you extractWhere you store itUsed in
Loginaccess_token from the bodyCollection or environment variableAuthorization header of every later call
Create order (POST)id of the new orderEnvironment variable orderIdGET, PATCH and DELETE URLs
Fetch order (GET)status and totalLocal variables in the testAssertions comparing with what was sent
Cancel order (DELETE)Nothing; check status codeNot neededFinal 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);
order-chain.postman.js

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.

Key insight: If you copy a value by hand from one response to another during a live task, expect the question 'how would you automate that?'. Have the variable approach ready before you are asked.

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 categoryExample requestExpected responseWhy it matters
Missing required fieldPOST /orders without productId400 with a message naming productIdClients must know what to fix
Wrong data typeqty: "two" instead of 2400 or 422 with a type errorPrevents bad data reaching the database
Boundary valueqty: 0 and qty: 101 when the limit is 1-100400 for both, 201 for 1 and 100Limits are where bugs hide
Access to another user's dataGET /orders/{otherUsersId}403 or 404, never the dataData 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");
});
negative-tests.postman.js

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.

Remember: When you name a negative test, always add the expected status and what the message should say. 'Send invalid data' is an idea; '400 with a message naming productId' is a test case.

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 typeSingle-field check catches it?Schema check catches it?Real-world effect
total changes from number to stringOnly if you assert on totalYes, type mismatchApp calculations break or show NaN
Required field missingOnly if it is the field you checkYes, required listScreen shows blank or crashes
Unexpected null valueRarelyYes, if type excludes nullNull errors in client code
Extra field addedNoOnly if additionalProperties is falseUsually 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
}
order-schema.json

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.

Pro move: Mention who owns the schema. Saying 'we kept schemas in the repo next to the tests and updated them when the API contract changed' shows you understand schema checks as a team agreement, not just a test trick.
How Uncodemy helps: Uncodemy trainers cover APIs interview questions as part of the API Automation Testing Training Course: project reviews, mock interviews and resume feedback, with placement assistance once you are interview-ready.

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
api-practice-workflow.md

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.
Pro tip: Time yourself building the full practice collection from scratch. When you can do it calmly in about thirty minutes, live API tasks stop feeling like a test and start feeling like normal work.

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 / 5

Pick 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.

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