Why API Testing in Cypress? Combining UI and API Verification in One Tool

Most QA teams use separate tools for API testing (Postman, REST Assured) and UI testing (Cypress, Selenium). This split creates blind spots: your Postman tests verify the API returns correct data, and your Cypress tests verify the UI displays data correctly — but nobody verifies that the UI correctly interprets what the API returns. Cypress bridges this gap with cy.request(), letting you send HTTP requests directly from your test suite. You can validate API responses, use API calls to set up test state, and combine API and UI assertions in a single test.

The Case for API Testing Inside Cypress #

API testing in Cypress is not a replacement for dedicated API test suites — it is a complement that enables three powerful patterns: faster test setup, API-level validation alongside UI checks, and end-to-end contract verification.

// Three reasons to test APIs in Cypress

// ── REASON 1: Faster test setup ──
// Instead of clicking through 5 pages to create an order:
// cy.visit('/shop'); cy.addToCart(0); cy.get('.checkout').click(); ...

// Use one API call:
cy.request('POST', '/api/orders', {
  items: [{ productId: 1, quantity: 2 }],
  shippingAddress: { city: 'London', postcode: 'SW1A 1AA' },
}).then((response) => {
  expect(response.status).to.eq(201);
  const orderId = response.body.id;
  // Now verify the UI displays this order correctly
  cy.visit(`/orders/${orderId}`);
  cy.get('[data-cy="order-status"]').should('contain.text', 'Pending');
});


// ── REASON 2: API-level validation ──
// Verify the API contract independently of the UI

cy.request('GET', '/api/products').then((response) => {
  expect(response.status).to.eq(200);
  expect(response.body).to.be.an('array').with.length.greaterThan(0);
  expect(response.body[0]).to.have.all.keys(
    'id', 'name', 'price', 'description', 'imageUrl', 'inStock'
  );
  expect(response.body[0].price).to.be.a('number').and.be.greaterThan(0);
});


// ── REASON 3: Combined API + UI assertion ──
// Verify the UI accurately reflects the API data

cy.request('GET', '/api/products').then((apiResponse) => {
  const apiProducts = apiResponse.body;

  cy.visit('/shop');

  // Verify the UI shows the same number of products as the API
  cy.get('.product-card').should('have.length', apiProducts.length);

  // Verify the first product's name matches API data
  cy.get('.product-card').first()
    .find('.product-name')
    .should('have.text', apiProducts[0].name);

  // Verify the first product's price matches API data
  cy.get('.product-card').first()
    .find('.product-price')
    .should('contain.text', `$${apiProducts[0].price.toFixed(2)}`);
});


// ── cy.request vs cy.intercept — different tools, different purposes ──

const COMPARISON = {
  'cy.request()': {
    what: 'Sends a REAL HTTP request from the Cypress Node.js server',
    when: 'API validation, test setup, data seeding, authentication',
    scope: 'Independent of the browser — works without cy.visit()',
    returns: 'Full response: status, headers, body, duration',
  },
  'cy.intercept()': {
    what: 'Intercepts requests made BY THE BROWSER (the app under test)',
    when: 'Stubbing responses, waiting for app requests, modifying payloads',
    scope: 'Only catches requests from the browser — not from cy.request()',
    returns: 'Interception object with request and response details',
  },
};

Common Mistakes #

Mistake 1 — Using cy.visit() + UI clicks for test setup when cy.request() is faster #

❌ Wrong: Creating a test order by navigating through 5 pages of the checkout flow in beforeEach() — adds 10 seconds per test.

✅ Correct: cy.request('POST', '/api/orders', orderData) — creates the order in milliseconds, then cy.visit('/orders/id') to verify the UI displays it.

Mistake 2 — Confusing cy.request() with cy.intercept() #

❌ Wrong: Using cy.request() to “intercept” the application’s API calls — it cannot do this; it sends its own requests.

✅ Correct: Using cy.request() for sending test requests and cy.intercept() for monitoring/stubbing the application’s requests.