ST API Testing Interview Questions & Answers

by

1️⃣ Authentication & Authorization Issues

One of the most common challenges is handling different authentication mechanisms.

Real‑time scenarios:

  • OAuth2 token expiry during long test runs
  • Token generated successfully but not accepted by downstream services
  • Role‑based APIs returning 403 Forbidden even after successful login

How I handled it:

  • Automated token generation and refresh
  • Validated roles/claims inside JWT tokens
  • Added negative tests for invalid/expired tokens

2️⃣ Dependency on Upstream / Downstream APIs

APIs are rarely standalone; they depend on other services.

Example:

  • Order API depended on Inventory API
  • Inventory API was unstable in QA → Order API tests failed

Challenge:

  • Hard to identify whether the defect belongs to our service or dependent service

Solution:

  • Used mock services / stubs
  • Isolated API testing at service level before E2E validation

3️⃣ Incomplete or Changing API Documentation

This is a very real pain point.

Real‑time issues:

  • Swagger not updated
  • Mandatory fields missing in documentation
  • Response fields changed without notice

Impact:

  • Automation scripts started failing
  • False defects raised initially

Mitigation:

  • Validated APIs using actual response schema
  • Maintained contract test cases
  • Frequent sync with dev team

4️⃣ Dynamic Response Data Validation

Validating dynamic values is tricky.

Examples:

  • Auto‑generated IDs
  • Timestamps
  • Encrypted values

Challenge:

  • Hard‑coded assertions fail

Approach:

  • Validated data types, patterns, and partial matches
  • Compared API response with DB values where applicable

5️⃣ Environment & Configuration Issues

APIs behave differently across environments.

Real‑time scenario:

  • API worked in QA but failed in UAT due to:
    • Wrong base URL
    • Missing headers
    • Feature flags disabled

Solution:

  • Environment‑specific config files
  • Health‑check APIs before execution

6️⃣ Error Handling & Negative Scenarios

APIs often return:

  • Incorrect HTTP status codes
  • Generic error messages
  • No error body at all

Example:

  • API returned 200 OK even for invalid input

Challenge:

  • Business validation vs technical validation mismatch

Action:

  • Raised defects highlighting incorrect REST standards
  • Added negative test cases explicitly

7️⃣ Data Setup & Cleanup

APIs require clean test data.

Issues faced:

  • Duplicate data errors
  • Dirty data affecting parallel execution

Solution:

  • Pre‑condition APIs / DB scripts for setup
  • Post‑execution cleanup
  • Unique test data generation

8️⃣ Performance & Timeout Issues

During integration testing:

  • APIs worked functionally but failed under load
  • Random timeouts caused flaky automation results

Handling:

  • Added response‑time assertions
  • Coordinated with performance team early

1️⃣ Validate HTTP Status Code (First Gate)

I always start with the status code, because it tells whether the request was handled correctly at protocol level.

Examples:

  • 200 / 201 → Successful response
  • 400 → Bad request (client issue)
  • 401 / 403 → Authentication / authorization issue
  • 500 → Server error

✅ If the status code is wrong, the response is already incorrect, even if the body looks fine.

2️⃣ Validate Response Body Structure (Schema Validation)

Next, I validate whether the response structure matches the contract (Swagger / OpenAPI).

I check:

  • Mandatory fields are present
  • Data types are correct (string, number, boolean)
  • No unexpected fields are returned

3️⃣ Validate Business Data (Most Important)

A technically correct response can still be functionally wrong.

Real‑time example:

  • API returns 200 OK
  • But account balance is incorrect

What I validate:

  • Actual values vs expected values
  • Field‑to‑field comparison
  • Calculated values (totals, taxes, discounts)

4️⃣ Validate Headers & Security

I verify:

  • Content‑Type (application/json)
  • Authorization token presence
  • Cache‑control headers (if applicable)

5️⃣ Validate Error Handling (Negative Scenarios)

For invalid inputs, I check:

  • Correct error code
  • Meaningful error message
  • Consistent error structure

Example:

  • Invalid request → 400
  • Clear message like "Invalid accountId"

6️⃣ Validate Performance & Response Time

Even if everything else is correct:

  • Slow APIs are considered defective

I validate:

  • Response time within SLA
  • No unexpected timeouts

OAuth 1.0 secures every request using cryptographic signatures, making it complex and outdated, whereas OAuth 2.0 uses token‑based authorization with multiple grant types, making it simpler, scalable, and the industry standard for modern applications.

When the nested JSON response is dynamic (keys/arrays/order can change), I validate it in layers instead of doing hard‑coded field‑to‑field assertions.

1) Validate “contract” using JSON Schema (best baseline)

I keep a schema that enforces:

  • required top‑level fields exist (status, data, etc.)
  • data types are correct (string/number/boolean)
  • allows unknown/dynamic fields using additionalProperties: true
  • uses flexible rules for dynamic arrays (minItems, item schema)

In real API automation (Rest Assured), I’ve used jsonSchemaValidator with Hamcrest matchers for schema + key validations, especially when payload shape evolves frequently.

given()
  .when().get("/orders/123")
  .then()
  .statusCode(200)
  .body(matchesJsonSchemaInClasspath("schemas/order.schema.json"));

 2) Use JSONPath with wildcards/filters for dynamic nesting

When indexes and node positions vary, I avoid fixed paths like data.items[0].id. Instead I use:

  • wildcard: items*.id / items[*].id
  • filter: items.findAll { it.type == 'PRIMARY' }.id

Example:

List<String> ids = jsonPath.getList("data.items.findAll { it.active == true }.id");
assertThat(ids, not(empty()));

 

For arrays of JSON objects, I extract fields using JSONPath/JS mapping and validate based on conditions (find/filter) and invariants (every item has required fields), instead of relying on fixed indexes—this makes tests stable even when data is dynamic.

Response res = given().when().get("/users");
List<Integer> ids = res.jsonPath().getList("users.id");
assertThat(ids, hasSize(greaterThan(0)));

When an API field returns dynamic data types, I validate it using conditional type checks or flexible JSON schema (oneOf), normalize values for assertions, and flag inconsistent typing as a design concern if it violates the API contract.

I extract the field and check its runtime type, then validate accordingly.

Object amount = response.jsonPath().get("data.amount");

if (amount instanceof Integer || amount instanceof Float || amount instanceof Double) {
    assertThat(((Number) amount).doubleValue(), greaterThan(0.0));
} else if (amount instanceof String) {
    assertThat((String) amount, matchesPattern("\\d+(\\.\\d+)?"));
} else if (amount == null) {
    // allowed scenario
} else {
    fail("Unexpected data type for amount");
}

First: Confirm Rate‑Limit Policy (Very Important)

Before automation changes, I validate:

  • Requests per second/minute allowed
  • Burst limits
  • Cool‑down window
  • Whether limits differ per environment (QA vs PROD)

This aligns with traffic management and throttling practices recommended in enterprise API guidelines.

✅ If limits are undocumented → I raise a clarification request.

Respect Retry‑After Header (Best Practice)

Most APIs return a Retry-After header with 429.

✅ Correct handling:

  • Read Retry‑After
  • Wait for that duration
  • Retry the request

Example (Rest Assured / Java – pseudo logic)

 

if (response.statusCode() == 429) {
    int waitTime = Integer.parseInt(response.getHeader("Retry-After"));
    Thread.sleep(waitTime * 1000);
    retryRequest();
}

✅ What is a multipart/form-data response?

A multipart/form-data response contains multiple parts in a single HTTP response, separated by boundaries.
Each part can have:

  • Its own headers
  • Its own content type (JSON, XML, file, text, binary)

Typical real‑world examples:

  • File download + metadata JSON
  • PDF + status info
  • Image + validation response
  • Multiple files in one response

✅ My Overall Strategy

I never treat multipart responses as plain JSON.
Instead, I:

  1. Validate headers and boundaries
  2. Split the response into parts
  3. Validate each part independently
  4. Apply content‑specific assertions

1️⃣ Validate Response Headers First

Before parsing the body, I validate:

  • HTTP status code
  • Content-Type contains multipart/form-data
  • Presence of a boundary

✅ Example check:

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXYZ

 

What Is an API?

An API (Application Programming Interface) is a contract or interface that allows two software components to communicate with each other.
It defines how requests should be made, what data is expected, and what response will be returned.

Key points:

  • APIs can be local or remote
  • They can use any protocol (HTTP, TCP, gRPC, WebSockets, or even in‑process method calls)
  • Data formats can be JSON, XML, binary, or custom
  • APIs are not limited to the web

Example:

  • A Java library method
  • An OS file system API
  • A REST API used by a mobile app

What Is a Web Service?

A Web Service is a specific type of API that:

  • Always works over a network
  • Uses web protocols like HTTP/HTTPS
  • Is designed for machine‑to‑machine communication over the internet

Common types of web services:

  • SOAP (XML‑based, strict standards)
  • RESTful services (JSON/XML over HTTP)

Key point:

All web services are APIs, but not all APIs are web services.

Protocols Used in API Testing

1. HTTP / HTTPS

This is the most commonly used protocol for API testing.

  • Used by REST, SOAP, GraphQL APIs
  • Supports standard HTTP methods: GET, POST, PUT, DELETE, PATCH
  • HTTPS adds encryption using TLS/SSL

Used for:
Web APIs, microservices, public and internal APIs

REST (Representational State Transfer)

REST is an architectural style built on top of HTTP/HTTPS.

  • Stateless communication
  • Uses JSON or XML payloads
  • Resource‑based endpoints

1️⃣ Request Validation

Verify that the API correctly handles incoming requests:

  • Correct HTTP method (GET, POST, PUT, DELETE)
  • Mandatory and optional request parameters
  • Request headers (Content‑Type, Authorization, Accept)
  • Request payload structure and data types
  • Boundary values and invalid inputs

2️⃣ Response Validation

Ensure the API response is correct and consistent:

  • HTTP status codes (200, 201, 400, 401, 403, 404, 500)
  • Response body structure (JSON / XML)
  • Field names, data types, and values
  • Mandatory vs optional response fields
  • Null and empty values handling

3️⃣ Business Logic Validation

Confirm the API enforces business rules correctly:

  • Correct calculations and transformations
  • Conditional flows based on input data
  • Data consistency across multiple APIs
  • Validation of success and failure scenarios
  • Correct error messages for business rule violations

4️⃣ Data Integrity & Database Validation

Verify backend data accuracy:

  • Data is correctly inserted, updated, or deleted in DB
  • No duplicate or inconsistent records
  • Correct data mapping between request and database
  • Transaction handling (commit / rollback)
  • Data consistency across integrated systems

5️⃣ Error Handling & Negative Scenarios

Validate how the API behaves under failure conditions:

  • Invalid inputs and missing parameters
  • Unauthorized and forbidden access
  • Proper error codes and messages
  • No sensitive information exposed in errors
  • Graceful handling of unexpected failures

6️⃣ Authentication & Authorization

Ensure API security is enforced:

  • API keys, tokens, OAuth, or basic authentication
  • Token expiry and refresh handling
  • Role‑based access control
  • Unauthorized users cannot access protected endpoints

7️⃣ Performance & Reliability

Check API stability and speed:

  • Response time under normal load
  • Behavior under high concurrency
  • Rate limiting and throttling
  • Timeout handling
  • Stability during long‑running requests

8️⃣ Integration Validation

Validate interaction with dependent systems:

  • Downstream service calls
  • Third‑party integrations
  • Message queues or event triggers
  • Proper fallback when dependencies are unavailable

9️⃣ Schema & Contract Validation

Ensure API contract compliance:

  • API follows defined contract (Swagger / OpenAPI)
  • Backward compatibility
  • Versioning behavior
  • Field deprecation handling

🔟 Security Testing

Verify API is not vulnerable:

  • SQL injection and script injection
  • Input validation
  • HTTPS enforcement
  • Sensitive data masking
  • Header security checks

What is an API?

An API (Application Programming Interface) is a general interface or contract that allows software components to communicate. APIs can work locally or remotely, and they are not limited to the web. They can use multiple protocols and data formats.

 What is a Web Service?

A Web Service is a specific type of API that always communicates over a network, using web protocols such as HTTP/HTTPS. It follows web standards and is designed for interoperability between systems over the internet.

🔹 What is SOAP?

SOAP (Simple Object Access Protocol) is a strict, protocol‑based approach for building APIs. It relies heavily on XML and follows a formal contract (WSDL) that defines how the service should behave. SOAP is designed with enterprise‑level security, reliability, and transactional integrity in mind.

🔹 What is REST?

REST (Representational State Transfer) is an architectural style, not a protocol. REST APIs are built on top of HTTP/HTTPS, are lightweight, and commonly use JSON for data exchange. REST focuses on simplicity, scalability, and performance.

✅ What Is JSON?

JSON (JavaScript Object Notation) is a lightweight data‑interchange format used to represent and exchange data between systems.

Key points:

  • Holds actual data
  • Human‑readable and machine‑parsable
  • Used in API requests, responses, config files
  • No built‑in validation rules

Example (JSON data):

{
  "name": "Alice",
  "age": 30,
  "isActive": true
}

JSON only represents data—it does not define whether the data is valid or complete.

✅ What Is JSON Schema?

JSON Schema is a specification (written in JSON) that defines rules, structure, and constraints for JSON data.

Key points:

  • Acts as a blueprint or contract
  • Defines data types, required fields, limits, patterns
  • Used for validation, documentation, and API contracts
  • Ensures data consistency and integrity

Example (JSON Schema):

{
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "age": { "type": "integer", "minimum": 0 }
  },
  "required": ["name", "age"]
}

This schema validates whether incoming JSON matches the expected structure.

 

🔹 Path Parameters

Path parameters are part of the URL path and are used to identify a specific resource.

Key characteristics:

  • Mandatory
  • Identify which resource is being accessed
  • Usually represent IDs or unique values
  • Appear inside the URL path

Example:

GET /users/101
  • 101 is a path parameter
  • It uniquely identifies a user

🔹 Query Parameters

Query parameters are used to filter, sort, paginate, or modify the response.

Key characteristics:

  • Optional
  • Do not identify the resource
  • Used for searching, filtering, pagination
  • Appear after ? in the URL

Example:

GET /users?role=admin&page=2
  • role and page are query parameters.
  • They refine the result set

Handling Timeouts in Rest Assured

Timeouts prevent tests from hanging indefinitely when an API is slow or unresponsive. Rest Assured uses Apache HTTP Client, so timeouts are configured at the HTTP‑client level.

🔹 Types of Timeouts

  • Connection Timeout – Time to establish a connection
  • Socket (Read) Timeout – Time to wait for response data
  • Connection Request Timeout – Time to get a connection from pool
import io.restassured.RestAssured;
import io.restassured.config.HttpClientConfig;
import io.restassured.config.RestAssuredConfig;
import org.apache.http.client.config.RequestConfig;
import org.apache.http.impl.client.HttpClientBuilder;

RequestConfig requestConfig = RequestConfig.custom()
        .setConnectTimeout(5000)   // connection timeout
        .setSocketTimeout(5000)    // read timeout
        .build();

RestAssured.config = RestAssuredConfig.config()
        .httpClient(HttpClientConfig.httpClientConfig()
        .httpClientFactory(() ->
                HttpClientBuilder.create()
                .setDefaultRequestConfig(requestConfig)
                .build()));

 This ensures tests fail fast when APIs exceed expected response times.

Handling Retries in Rest Assured

Rest Assured does not provide built‑in retry support, so retries are implemented using custom logic or helper libraries.

 

int maxRetries = 3;
int delay = 2000;

for (int attempt = 1; attempt <= maxRetries; attempt++) {
    Response response = RestAssured.get("https://api.example.com/resource");

    if (response.getStatusCode() == 200) {
        break;
    }

    Thread.sleep(delay);
}

1. Validate Against a Set of Acceptable Status Codes

Instead of asserting a single value, validate against allowed outcomes.

int statusCode =
    given()
        .when()
        .post("/orders")
        .getStatusCode();

assertThat(statusCode,
    anyOf(is(200), is(201), is(202)));

 2. Conditional Assertions Based on Status Code

Assert different validations depending on the response.

Response response =
    given()
        .when()
        .get("/payment/status");

int status = response.getStatusCode();

if (status == 200) {
    response.then().body("status", equalTo("COMPLETED"));
} else if (status == 202) {
    response.then().body("status", equalTo("IN_PROGRESS"));
} else {
    fail("Unexpected status code: " + status);
}

 

Intermittent API failures usually point to environment instability, timing issues, or data dependency problems, not functional defects.

Debugging approach

  • First, identify failure patterns
    • 특정 endpoints?
    • Only during peak load?
    • Specific environments?
  • Check response codes and latency
    • 5xx → backend issues
    • 429 → rate limiting
    • Timeouts → infra/network delays
  • Enable Postman Console & Newman logs
    • Inspect headers, tokens, payload size
  • Re‑run the failing request independently
    • Confirms test issue vs API issue
  • Add timestamps and correlation IDs
    • Helps backend teams trace intermittent errors

Stabilization

  • Avoid hard‑coded test data
  • Remove execution order dependencies
  • Add retries only for known flaky endpoints
  • Fail fast on auth or config issues

Dynamic tokens are handled centrally and reused across collections.

Strategy

  • Generate token once per run
  • Store it in environment variables
  • Automatically refresh on expiry

Collection‑level pre‑request script

if (!pm.environment.get("access_token")) {
    pm.sendRequest(pm.environment.get("auth_request"), (err, res) => {
        pm.environment.set("access_token", res.json().access_token);
    });
}

 Token expiry handling

  • Decode JWT → check exp
  • Regenerate token if expired
  • Prevent token regeneration on every request

Best practices

  • Never duplicate auth logic in requests
  • No hardcoded secrets
  • CI secrets injected via pipeline variables

Postman doesn’t support retries natively, so retry logic is implemented programmatically.

let retries = pm.environment.get("retry") || 0;

if (pm.response.code >= 500 && retries < 2) {
    pm.environment.set("retry", retries + 1);
    postman.setNextRequest(pm.info.requestName);
} else {
    pm.environment.unset("retry");
}

Pipeline‑level retry (Recommended)

  • Configure Newman retries in CI
  • Retry only on specific failures (5xx, timeout)
  • Avoid retrying validation failures

Key principle Retries should mask instability, not hide real bugs.

Large payload testing focuses on performance, limits, and stability, not just correctness.

Approach

  • Use external JSON files (don’t embed data in Postman)
  • Parameterize payload size
  • Execute via Newman (Postman UI is limited)

Validations

  • Status code (200 / 413 expected)
  • Response time
  • SLAMemory / timeout errors
  • Partial processing failures
pm.test("Response time under SLA", () => {
    pm.expect(pm.response.responseTime).to.be.below(3000);
});

});
Show more lines

Best practices

  • Avoid assertion loops on large arrays
  • Validate structure, counts, and checksumsSeparate functional vs performance payload tests

This is done using end‑to‑end contract validation, not direct DB access in Postman.

Industry‑accepted approach

  • API‑to‑API validation
  • DB validation using backend test utilities
  • Automation orchestration via CI

API‑to‑DB flow

  1. Call Create API
  2. Extract business key (ID)
  3. Validate via
    • Read API
    • DB verification script (Java/Python)
  4. Compare:
    • Mandatory fields
    • Data transformations
    • Null handling
    • Status flags

Postman role

JavaScript

pm.environment.set(“userId”, pm.response.json().id);
Show more lines

DB validation (outside Postman)

  • JDBC / ORM queries
  • Schema checks
  • Referential integrity validation

What NOT to do

  • DB calls directly from Postman
  • Hardcoded DB credentials
  • UI‑dependent DB validation

Avatar for Softwaretestingo Editorial Board

I love open-source technologies and am very passionate about software development. I like to share my knowledge with others, especially on technology that's why I have given all the examples as simple as possible to understand for beginners. All the code posted on my blog is developed, compiled, and tested in my development environment. If you find any mistakes or bugs, Please drop an email to softwaretestingo.com@gmail.com, or You can join me on Linkedin.

Leave a Comment