API Testing Interview Questions for QA Engineers: What to Expect

API testing interviews test two things: conceptual knowledge of HTTP methods, status codes, and auth flows, and practical judgment about what to actually verify on each response. The questions that trip candidates up are scenario-based: how to test a DELETE endpoint completely, how to handle authentication across a test suite, and why a 500 response to invalid input is itself a bug. Each question below includes what the interviewer is checking and an answer that demonstrates hands-on experience, not just definitions.

Foundational Questions

1. "What is API testing and why is it important?"

2. "What's the difference between API testing and UI testing?"

| | API Testing | UI Testing |

|-|-------------|------------|

| What's tested | Request/response, business logic | User interface, visual elements, user flows |

| Speed | Very fast (milliseconds) | Slower (seconds, browser startup) |

| Stability | High — no DOM changes | Lower — UI selectors break |

| Coverage | Business logic, security, data integrity | User experience, visual correctness |

| Tools | Playwright request API, Postman, REST Assured | Playwright, Cypress, Selenium |

Neither replaces the other — they catch different bugs.

3. "What do you verify in an API test?"

A strong API test checks:

• Status code — is it 200 when it should be 201? Is a missing auth token returning 401?
• Response body — are the correct fields present? Are values correct?
• Data types — is age a number or a string? Is is_active a boolean?
• Required fields — missing or null fields that should be present
• No sensitive data leaked — password hashes, internal IDs, PII that shouldn't be in the response
• Error responses — do invalid requests return helpful error messages with the right status code?
• Performance — does the response come back within an acceptable time?

4. "Explain the HTTP methods you use in API testing."

| Method | Purpose | Example |

|--------|---------|---------|

| GET | Retrieve data | Get a user's profile |

| POST | Create new resource | Register a new user |

| PUT | Replace a resource entirely | Update all user fields |

| PATCH | Update part of a resource | Update just the user's email |

| DELETE | Remove a resource | Delete a user account |

5. "What status codes do you check most in API testing?"

Rather than listing all status codes, give a testing-oriented answer:

Tool and Implementation Questions

6. "How do you test APIs in Playwright?"

test('POST /users returns 201 with correct body', async ({ request }) => {
  const response = await request.post('https://api.becomeqa.com/users', {
    data: {
      email: 'new_user@test.com',
      password: 'ValidPass1',
      role: 'member',
    },
  });

  expect(response.status()).toBe(201);
  
  const body = await response.json();
  expect(body.id).toBeTruthy();
  expect(body.email).toBe('new_user@test.com');
  expect(body).not.toHaveProperty('password'); // no password in response
});

7. "How do you handle authentication in API tests?"

let authToken: string;

test.beforeAll(async ({ request }) => {
  const response = await request.post('/api/auth/login', {
    data: { email: 'admin@test.com', password: 'AdminPass1' },
  });
  const body = await response.json();
  authToken = body.token;
});

test('authenticated request works', async ({ request }) => {
  const response = await request.get('/api/users', {
    headers: { Authorization: `Bearer ${authToken}` },
  });
  expect(response.status()).toBe(200);
});

8. "What's the difference between Postman and Playwright for API testing?"

| | Postman | Playwright |

|-|---------|-----------|

| Type | GUI tool for manual + scripted testing | Code-based automation framework |

| Good for | Exploratory API testing, quick checks, mocking | Automated test suites, CI/CD, E2E + API combined |

| Learning curve | Low | Moderate (requires programming) |

| CI/CD integration | Possible (Newman CLI) | Native, first-class |

| Test code quality | Limited | Full TypeScript support |

| Debugging | Visual request/response viewer | Logs, trace viewer |

Scenario-Based Questions

9. "You're testing a DELETE endpoint. What do you verify?"

A complete DELETE endpoint test should check:

1. Happy path: Delete a resource with valid auth → 204 No Content

2. Resource actually deleted: Follow-up GET → 404

3. Idempotency: Second DELETE → 404 (not 500, not 204 again)

4. Authorization: Delete without auth → 401

5. Wrong user: Delete someone else's resource → 403

6. Non-existent resource: Delete resource that was never created → 404 (not 500)

test('DELETE /orders/:id full coverage', async ({ request }) => {
  // Create order to delete
  const createResp = await request.post('/api/orders', { 
    data: { product_id: 1, quantity: 2 },
    headers: { Authorization: `Bearer ${userToken}` },
  });
  const { id } = await createResp.json();

  // Delete it
  const deleteResp = await request.delete(`/api/orders/${id}`, {
    headers: { Authorization: `Bearer ${userToken}` },
  });
  expect(deleteResp.status()).toBe(204);

  // Verify it's gone
  const getResp = await request.get(`/api/orders/${id}`, {
    headers: { Authorization: `Bearer ${userToken}` },
  });
  expect(getResp.status()).toBe(404);

  // Second delete → 404, not crash
  const redoResp = await request.delete(`/api/orders/${id}`, {
    headers: { Authorization: `Bearer ${userToken}` },
  });
  expect(redoResp.status()).toBe(404);
});

10. "How do you test API error handling?"

Test checklist:

• Required field missing → 400/422 with clear error message
• Wrong data type (string where number expected) → 400/422
• Value out of range → 400/422
• Valid JSON but fails business logic (duplicate email) → 409
• Malformed JSON body → 400
• Missing Content-Type header → 400 or 415

11. "What's contract testing and when would you use it?"

Contract testing verifies that an API adheres to an agreed-upon contract — the specification of what requests and responses should look like. Tools like Pact define these contracts between consumer (frontend) and provider (backend).

12. "How do you test pagination in an API?"

test('pagination returns correct page sizes', async ({ request }) => {
  // First page
  const page1 = await request.get('/api/products?page=1&limit=10');
  const body1 = await page1.json();
  expect(body1.data).toHaveLength(10);
  expect(body1.pagination.current_page).toBe(1);
  expect(body1.pagination.total_pages).toBeTruthy();

  // Second page
  const page2 = await request.get('/api/products?page=2&limit=10');
  const body2 = await page2.json();
  // Different items from page 1
  expect(body2.data[0].id).not.toBe(body1.data[0].id);

  // Last page
  const lastPage = await request.get(`/api/products?page=${body1.pagination.total_pages}&limit=10`);
  const bodyLast = await lastPage.json();
  expect(bodyLast.data.length).toBeGreaterThan(0);
  expect(bodyLast.data.length).toBeLessThanOrEqual(10);

  // Beyond last page
  const overPage = await request.get(`/api/products?page=${body1.pagination.total_pages + 1}&limit=10`);
  expect(overPage.status()).toBe(200); // or 404, depends on API design
  const bodyOver = await overPage.json();
  expect(bodyOver.data).toHaveLength(0); // or empty array
});

What Interviewers Want to See

Beyond getting the answers right, interviewers notice: