API Testing Interview Questions 2026 — What SDET Panels Ask About REST, Postman & Contract Testing

It's 11pm. Your SDET interview is tomorrow morning. You've nailed down your Playwright locator strategies. You can discuss fixture scoping and CI/CD pipelines without breaking a sweat. Then you remember the job description had that line buried halfway down: "Experience with API testing — REST, Postman, contract testing."

Your stomach tightens. You've written API tests before — a few fetch() calls in a test script, maybe poked around in Postman. But you've never been interviewed on it. You don't know whether they'll ask about REST vs SOAP, HTTP status codes, authentication flows, or something called "contract testing" that you've only seen mentioned in blog posts.

This guide is for that moment. API testing comes up in nearly every SDET interview — and if you can't speak to it with confidence, you're leaving the door open for a candidate who can. Built from 20 years of sitting on both sides of the SDET interview table — at HMRC, the Ministry of Defence, Nationwide, and Accenture — this guide covers exactly what interviewers ask about API testing, the questions that trip up candidates who've only tested UIs, and how SDET Interview Coach prepares you for the API testing round so you walk in ready — even if API testing isn't your primary stack.

Why API Testing Questions Are Gatekeeping SDET Jobs in 2026

Three years ago, many SDET interviews were satisfied with "I've used Postman to test endpoints." In 2026, that answer doesn't clear the phone screen. Here's what's changed:

• Microservices made API testing non-negotiable. When your application is 50 services talking to each other, the test surface isn't the UI — it's the contracts between those services. In panels at Nationwide and Accenture, Mitchell has watched interviewers shift from "Do you test APIs?" to "How do you test the API contracts between services?" The distinction matters.
• Playwright blurred the line between UI and API testing. Playwright's built-in request context means interviewers now expect SDETs to discuss API testing within the same framework they use for browser automation. If you can't explain when to use page.request vs request.newContext(), you're missing a capability half your competition has.
• Contract testing went from niche to mainstream. Pact, Spring Cloud Contract, and schema validation are appearing in job descriptions that didn't mention them a year ago. Organisations with distributed architectures need SDETs who understand that testing APIs in isolation isn't enough — you need to verify that services agree on the shape of their communication.

The API testing round isn't a pop quiz. It's a window into whether you understand testing at the integration layer — and in 2026, that's where most production bugs originate.

The 7 Categories Every API Testing Interview Covers

In panels Mitchell has conducted and observed across government and enterprise, API testing questions cluster into seven categories. You won't get asked all seven — but you'll get asked at least three. Master them all and you can handle any API testing curveball.

REST vs SOAP — The Question Every Panel Asks, and Most Candidates Answer Wrong

"What's the difference between REST and SOAP?" sounds like a softball. It isn't. Here's what interviewers at senior level are actually listening for:

HTTP Status Codes — The Hidden Interview Trap

Every candidate knows 200, 404, and 500. The interview doesn't start until you go beyond those. Here's what panels probe and why:

Authentication — The API Testing Round Where Candidates Freeze

In Mitchell's experience across interview panels at HMRC and the MoD, authentication questions expose the gap between "I've tested APIs" and "I understand API security." Here's what they're probing:

API Testing Code Examples — What Interviewers Expect You to Write

In many SDET interviews, you'll be asked to write an API test — either on a whiteboard, in a shared editor, or by explaining your approach. Here are the patterns that score well:

Playwright API Testing — The 2026 Standard

Playwright's built-in APIRequestContext is now the expected answer for API testing in a Playwright shop. Here's what a strong candidate writes:

import { test, expect } from '@playwright/test';

test.describe('User API', () => {
  let authToken: string;

  test.beforeAll(async ({ request }) => {
    // Authenticate and store the token for all tests
    const authResponse = await request.post('/auth/login', {
      data: { username: 'testuser', password: 'testpass' }
    });
    expect(authResponse.status()).toBe(200);
    const body = await authResponse.json();
    authToken = body.access_token;
  });

  test('GET /users returns paginated user list', async ({ request }) => {
    const response = await request.get('/users', {
      headers: { Authorization: `Bearer ${authToken}` },
      params: { page: 1, limit: 10 }
    });

    expect(response.status()).toBe(200);

    const body = await response.json();
    // Schema validation on response structure
    expect(body).toHaveProperty('data');
    expect(body).toHaveProperty('pagination');
    expect(Array.isArray(body.data)).toBeTruthy();
    expect(body.data.length).toBeLessThanOrEqual(10);
    expect(body.pagination).toMatchObject({
      page: 1,
      limit: 10,
      total: expect.any(Number)
    });
  });

  test('POST /users creates a user and returns 201', async ({ request }) => {
    const newUser = {
      name: 'Jane Smith',
      email: `jane-${Date.now()}`@example.com,
      role: 'editor'
    };

    const response = await request.post('/users', {
      headers: { Authorization: `Bearer ${authToken}` },
      data: newUser
    });

    expect(response.status()).toBe(201);
    expect(response.headers()['location']).toBeDefined();

    const body = await response.json();
    expect(body.name).toBe('Jane Smith');
    expect(body.id).toBeDefined();
  });

  test('GET /users/:id with invalid token returns 401', async ({ request }) => {
    const response = await request.get('/users/123', {
      headers: { Authorization: 'Bearer invalid_token' }
    });
    expect(response.status()).toBe(401);
  });
});

Notice what this code demonstrates: authToken is scoped at the describe level and set in beforeAll (no per-test auth calls), data uniqueness is handled with Date.now() (no hard-coded test data), schema validation is performed on response structure, status code validation covers 200, 201, and 401, and negative testing (invalid token) is included alongside happy-path tests. This is the pattern that signals a senior-level API tester.

Supertest + Jest — The Node.js Approach

If your target company uses Node.js backends, expect Supertest questions:

import request from 'supertest';
import app from '../app';

describe('Products API', () => {
  let server: any;
  let productId: string;

  beforeAll(async () => {
    server = app.listen(0);
  });

  afterAll(() => server.close());

  it('should create a product and return 201', async () => {
    const res = await request(server)
      .post('/api/products')
      .set('Authorization', `Bearer ${process.env.TEST_TOKEN}`)
      .send({ name: 'Widget', price: 9.99, category: 'tools' })
      .expect(201);

    expect(res.body).toMatchObject({
      id: expect.any(String),
      name: 'Widget',
      price: 9.99
    });
    productId = res.body.id;
  });

  it('should reject duplicate product names with 409', async () => {
    await request(server)
      .post('/api/products')
      .set('Authorization', `Bearer ${process.env.TEST_TOKEN}`)
      .send({ name: 'Widget', price: 9.99, category: 'tools' })
      .expect(409)
      .expect(res => {
        expect(res.body.error).toBe('DUPLICATE_PRODUCT');
      });
  });

  it('should reject invalid price with 422', async () => {
    await request(server)
      .post('/api/products')
      .set('Authorization', `Bearer ${process.env.TEST_TOKEN}`)
      .send({ name: 'Gadget', price: -5, category: 'tools' })
      .expect(422)
      .expect(res => {
        expect(res.body.errors).toContainEqual(
          expect.objectContaining({ field: 'price' })
        );
      });
  });
});

The key signals here: server lifecycle management (start/stop in hooks), auth via environment variables (no hard-coded tokens), business logic testing (duplicate products return 409, not 500), validation testing (negative prices return 422 with structured errors), and test chaining (the created product ID is reused without a hard-coded value).

5 API Testing Interview Traps That Cost Candidates Offers

These are the moments where interviewers stop taking notes and start waiting. They separate candidates who've tested APIs in production from those who've only explored them in Postman.

Schema Validation & Contract Testing — The Senior-Level Differentiator

If you're interviewing for a senior SDET or lead role, this is the section of the API testing round where the interviewer decides whether you're mid-level or senior. Here's what they're listening for:

What a Real API Testing Interview Round Looks Like — Timed Breakdown

Drawing from panels Mitchell has conducted at HMRC, Nationwide, and Accenture, here's how API testing questions typically appear in a 60-minute SDET interview:

Why API Testing Expertise Is the Fastest-Growing Premium in SDET Salaries

If you're thinking "I'll just focus on UI testing — that's what most SDET roles want," here's the reality: API testing is no longer a nice-to-have. It's the layer where most production incidents originate, and it's the layer where SDETs who can test both UI and API command a premium.

In recent panels at Accenture, Mitchell has watched compensation bands for SDETs who can design API testing strategies stretch 10–20% above UI-only roles. The reason is structural: microservices architectures mean the integration surface is overwhelmingly API-based. If you can only test through the browser, you're testing the outermost layer of an application with 50 internal services you never touch. That's a coverage gap no amount of UI testing can close.

More importantly, API testing expertise signals something interviewers care about deeply: you understand that testing happens at multiple layers, and you can architect a testing strategy that covers all of them. That's not an API testing skill — it's an architectural mindset. And it's what separates senior SDETs from mid-level testers.

How to Prepare for Your API Testing Interview — Starting Tonight

You don't need to have tested 50 microservices to pass an API testing interview. You need to understand the seven categories, be able to articulate API testing concepts clearly, and — most importantly — demonstrate that you can think about API testing as an engineering system, not a collection of Postman requests. Here's the 3-step plan:

1. Download SDET Interview Coach and complete the 2-minute onboarding assessment. Select your target stack and seniority level. The app surfaces API testing questions calibrated to your experience — Junior candidates get REST fundamentals and status code questions, while Lead candidates face contract testing strategy and cross-service test architecture discussions. The 800+ question bank includes dedicated API testing topics with model answers, code examples, and interviewer follow-up questions.
2. Run an API testing mock interview today. Pick your target stack, set a 30-minute timer, and answer the questions out loud. The AI feedback scores you on technical accuracy, completeness, communication, and code quality — showing you exactly where your API testing knowledge gaps are before the real interview exposes them.
3. Use Job Match for your target role. If the job description mentions "API testing," "REST," "Postman," "contract testing," or "microservices," paste it into Job Match. You'll get 50 questions tailored to that exact role's API testing expectations — no guessing whether they'll ask about OAuth flows, status code validation, or Pact contract testing.

The candidates who prepare for API testing questions now are the ones who'll walk into interviews with a skill that most of their competition treats as an afterthought. API testing isn't a separate discipline from SDET work — it's the integration layer that connects everything else. Master it, and you're not just a tester who can code. You're an engineer who understands how systems talk to each other.

If you're preparing for a broader SDET interview, see our guide on Playwright Interview Questions 2026 for web automation coverage, our deep-dive on Test Automation Framework Design for the system-design round, and our guide on transitioning from manual QA to SDET if you're making the career change. For mobile testing coverage, see our guide on Mobile Test Automation Interview Questions.