API Automation interview questions

API Automation questions a Automation developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.

Your test for POST /orders asserts the status is 201 and nothing else. What does that prove, and what do you add?
The strongest answer: Only that the endpoint answered. Add the body — the order id and its status — any header the client uses, and a read-back with GET to prove it was really stored
Why it works: Exactly — a status code is the envelope. The body and the read-back are the evidence.
- A status code is not an assertion.
- Assert the fields that matter.
- Read it back to prove storage.
- Check the headers clients rely on.
You have automated the happy path for POST /orders. Which negative cases go in next, and why those?
The strongest answer: No token and a wrong-role token — 401 against 403 — a missing required field, a malformed body, and an unknown product id; each has its own status and an error code clients branch on
Why it works: Right — and separating 401 from 403 is the check teams most often skip.
- One negative case per rule.
- Separate 401 from 403.
- Assert the error code, not the prose.
- Skip the combinatorial explosion.
What is a consumer-driven contract test for?
The strongest answer: To prove the provider still speaks the shape the consumer coded against — without standing up the whole UI or the whole fleet
Why it works: Exactly. It is a cheap conversation between two services. It is not the whole integration story.
- Prove the shape the consumer needs.
- Keep a few real integrations.
- Not traffic generation.
- Not an uptime check.
A team has a large Postman collection that only runs on one engineer’s laptop, with the staging password saved inside the collection.
How do you get it into CI?
The strongest answer: Run it with Newman in the pipeline, move every environment value into a CI secret or a variable file the collection reads, and emit a machine-readable report so failures show up as tests, not log lines
Why it works: Exactly — runner, secrets and report are the three things that turn a collection into a gate.
- Newman runs the collection in CI.
- Secrets come from the pipeline.
- Emit a report CI can render.
- A laptop-only check is not a gate.
The UI shows “Paid” but you do not trust the label. How do you assert?
The strongest answer: Check the UI and the source of truth — the payment API, the row, the event — so a lying badge cannot pass
Why it works: Exactly. Dual oracle: what the shopper sees and what the ledger says.
- UI plus ledger / API.
- Badges can lie.
- Do not skip the shopper.
- Humans after the run are not CI.
Where do consumer contract tests run?
The strongest answer: On the consumer PR against a published provider pact, and on the provider PR against consumer pacts — both sides, or it is a document not a gate
Why it works: Exactly. Both sides in CI or you have a brochure.
- Consumer CI + provider CI.
- Publish and verify.
- Not laptop-only.
- Not a wiki.
When do you validate a response against a JSON schema, and when do you assert on individual fields?
The strongest answer: Schema for the shape — types, required fields, enums — so a renamed or dropped field fails everywhere; field assertions for the values this particular test is about. One schema per response, a few values per test
Why it works: Exactly — shape and value are different questions, and one schema replaces dozens of type checks.
- Schema checks shape; asserts check values.
- One schema per response body.
- Assert only the values under test.
- A dropped field must fail something.
A provider broke a field the mobile app needs. Where should that have failed?
The strongest answer: On the provider pipeline, verifying consumer contracts, before the merge — not in the app store a week later
Why it works: Exactly. The provider gate is the cheap place. Store ratings are the expensive place.
- Fail on the provider PR.
- Contracts before the store.
- UI is a late witness.
- Breaking changes need a version, not a shrug.
Eighty REST Assured tests each repeat the same base URI, auth header, content type and the same three response assertions.
What do you introduce?
The strongest answer: A shared RequestSpecification and ResponseSpecification, built once and applied with given().spec(...) and then().spec(...), so the common setup and the common assertions live in one place per service
Why it works: Right — specs are the framework’s own answer to this, and they cover the response side too.
- Build the spec once per service.
- given().spec covers the request side.
- then().spec covers shared assertions.
- One place to change the auth header.
Provider teams ignore pact failures “because mobile can adapt.” What do you change?
The strongest answer: Make the broken contract fail their merge, and give them a versioned escape — adapt is a release, not a silent field drop
Why it works: Exactly. A gate plus a versioned break. Emails and deleted brokers are how you return to store bugs.
- Fail the provider merge.
- Offer a versioned break.
- Do not email-only.
- Do not delete the broker.
How do contracts survive a company with 40 services?
The strongest answer: A broker, provider gates, a small platform team that keeps the paved road, and product owners who accept versioned breaks — not a volunteer on Fridays
Why it works: Exactly. Contracts are an organisation. Volunteers and folklore do not survive 40 providers.
- Broker + provider gates.
- A platform owner.
- Versioned breaks.
- No folklore dialects.
To make the suite faster, a developer adds an endpoint that mints a session for any user id when a magic header is present. It is in the same build that ships to production.
What is your position?
The strongest answer: Not in the production build. If we keep it, it is compiled out or off by default outside test environments, gated by a secret that never leaves them, logged, and a check fails the pipeline if production answers it
Why it works: Right. The rule is that the shortcut cannot exist in production, and something proves that every build.
- No auth bypass in a production build.
- Compile it out, or default it off.
- Gate on a secret; log every use.
- Fail the build if production answers.
Mobile, web, and a partner all consume one API. How do contracts work?
The strongest answer: Each consumer publishes; the provider verifies the union on every change — a break is a version, not a surprise in three clients
Why it works: Exactly. Many consumers, one provider gate. Provider-written “canonical” is not consumer-driven.
- Publish every consumer.
- Provider verifies the union.
- Breaks are versions.
- Slack is not a contract.

API Automation interview questions

Your test for POST /orders asserts the status is 201 and nothing else. What does that prove, and what do you add?

You have automated the happy path for POST /orders. Which negative cases go in next, and why those?

What is a consumer-driven contract test for?

How do you get it into CI?

The UI shows “Paid” but you do not trust the label. How do you assert?

Where do consumer contract tests run?

When do you validate a response against a JSON schema, and when do you assert on individual fields?

A provider broke a field the mobile app needs. Where should that have failed?

What do you introduce?

Provider teams ignore pact failures “because mobile can adapt.” What do you change?

How do contracts survive a company with 40 services?

What is your position?

Mobile, web, and a partner all consume one API. How do contracts work?