
API Automation Testing
Is API TESTING possible in Cypress?
Most developers think Cypress is only for clicking buttons and filling forms. It is not. Cypress can test your entire API layer — requests, responses, headers, status codes, and even stubbed network traffic — without a browser in the loop. If you are doing QA or backend development in 2026, this is a capability you need to know.
Yes, Cypress Can Do API Testing
The short answer: yes, and it does it well.
Cypress gives you two powerful tools for API testing:
cy.request()— makes direct HTTP calls to your API, completely independent of the browser UI. Think of it as a scriptable HTTP client inside your test suite.cy.intercept()— sits between your frontend and your backend, letting you spy on, assert against, modify, or fully stub every network request your application makes.
Together these cover the two major API testing scenarios: testing the API directly, and testing how your frontend interacts with the API.
cy.request() — Direct API Testing
cy.request() is Cypress's built-in HTTP client. It sends real HTTP requests to your server and gives you full access to the response for assertions.// Basic GET request
cy.request('GET', '/api/users').then((response) => {
expect(response.status).to.eq(200)
expect(response.body).to.have.length.greaterThan(0)
})
// POST with body and headers
cy.request({
method: 'POST',
url: '/api/users',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer my-token'
},
body: {
name: 'Jane Doe',
email: '[email protected]'
}
}).then((response) => {
expect(response.status).to.eq(201)
expect(response.body).to.have.property('id')
expect(response.body.email).to.eq('[email protected]')
})
// DELETE and assert 204
cy.request('DELETE', '/api/users/1').its('status').should('eq', 204)
What you can assert on with
cy.request():response.status— HTTP status coderesponse.body— parsed response body (JSON auto-parsed)response.headers— response headersresponse.duration— how long the request tookresponse.requestHeaders— the headers that were sent
cy.intercept() — Network Interception and Stubbing
cy.intercept() is more powerful than cy.request() for integration testing. It intercepts real network traffic made by your running application and lets you assert on it, modify it, or replace it entirely with a stub.// Spy on a request and assert after
cy.intercept('GET', '/api/products').as('getProducts')
cy.visit('/products')
cy.wait('@getProducts').then(({ request, response }) => {
expect(response.statusCode).to.eq(200)
expect(response.body).to.be.an('array')
})
// Stub a response with fixture data
cy.intercept('GET', '/api/users', { fixture: 'users.json' }).as('getUsers')
cy.visit('/dashboard')
cy.wait('@getUsers')
cy.get('[data-testid="user-list"]').should('have.length', 3)
// Simulate error state
cy.intercept('POST', '/api/orders', {
statusCode: 500,
body: { error: 'Internal server error' }
}).as('failedOrder')
cy.visit('/checkout')
cy.get('[data-testid="submit-order"]').click()
cy.wait('@failedOrder')
cy.get('[data-testid="error-message"]').should('be.visible')
// Modify a response on the fly
cy.intercept('GET', '/api/config', (req) => {
req.reply((res) => {
res.body.featureFlag = true
return res
})
})
What You Can Test with Cypress API Testing
| Scenario | Tool | Example |
|---|---|---|
| Assert on response body | cy.request() / cy.intercept() | JSON fields, array length, nested properties |
| Assert on status codes | Both | 200, 201, 400, 401, 404, 500 |
| Assert on request headers | cy.intercept() | Authorization, Content-Type |
| Assert on response headers | Both | Cache-Control, CORS headers |
| Stub a response | cy.intercept() | Replace with fixture or hardcoded body |
| Simulate network errors | cy.intercept() | 500 errors, timeouts, empty responses |
| Delay a response | cy.intercept() | Test loading states and timeouts |
| Wait for a request to fire | cy.intercept() | .as() + cy.wait() |
| Test auth flows | cy.request() | Login, token refresh, logout |
| Seed test data via API | cy.request() | Create users/records before UI tests |
Cypress vs Other API Testing Tools
Cypress is not a replacement for dedicated API testing tools, but it covers ground that no other tool in your stack covers. Here is how it compares.
| Cypress | Postman | Supertest | REST Assured | |
|---|---|---|---|---|
| Primary use case | E2E + API integration | Manual + automated API testing | Node.js API unit testing | Java API testing |
| Frontend integration | Yes — tests UI + API together | No | No | No |
| Runs in CI/CD | Yes | Yes (Newman CLI) | Yes | Yes |
| Network stubbing | Yes (cy.intercept) | No | No | No |
| Language | JavaScript / TypeScript | Postman scripting | JavaScript | Java |
| Best for | Full-stack QA engineers | API exploration and contract testing | Backend unit tests | Java backends |
| Learning curve | Low for JS devs | Low | Low | Medium |
The key advantage Cypress brings: you can test the API and the UI response to that API in the same test. When your POST endpoint returns a 201, you can immediately assert that the UI updated correctly. No other tool does that in one step.
Common Patterns in Real QA Workflows
Pattern 1: Seed test data before UI tests
beforeEach(() => {
cy.request('POST', '/api/test/reset-db')
cy.request('POST', '/api/users', { name: 'Test User', email: '[email protected]' })
})
Pattern 2: Authenticate via API, not the UI
// Faster than typing into login form every test
cy.request('POST', '/api/auth/login', {
email: '[email protected]',
password: 'password123'
}).then(({ body }) => {
window.localStorage.setItem('token', body.token)
})
cy.visit('/dashboard')
Pattern 3: Intercept to test loading and error states
// Test the loading skeleton
cy.intercept('GET', '/api/data', (req) => {
req.reply({ delay: 2000, body: [] })
})
cy.visit('/page')
cy.get('[data-testid="skeleton"]').should('be.visible')
Pattern 4: Verify the exact request your frontend sends
cy.intercept('POST', '/api/checkout').as('checkout')
cy.get('[data-testid="buy-now"]').click()
cy.wait('@checkout').its('request.body').should('deep.include', {
productId: 'abc-123',
quantity: 1
})
Cypress API Testing and the QA Developer Path
API testing is one of the first skills that separates a QA engineer who can only test UIs from one who can test the full stack. Knowing how to write Cypress tests that cover both network behavior and UI responses is exactly the kind of skill that appears in QA job descriptions in 2026.
Cypress's official documentation has a working example of all network request commands at example.cypress.io/commands/network-requests — a useful reference when you are building out your first API test suite.
At Archi's Academy, the QA track covers testing in real project contexts — not just writing test syntax in isolation, but understanding what to test, how to structure a test suite, and how to write tests that actually catch bugs in production scenarios. That includes API testing with Cypress.
The difference between knowing that
cy.intercept() exists and knowing when to use it, what to stub versus what to test with real data, and how to integrate API tests into an end-to-end flow — that is the gap that matters in a real QA role.Ready to turn insights into real skills?
Start building with guided, project-based training and gain hands-on experience from day one.
Start Building Real QA and Backend Skills
Frequently Asked Questions
Can Cypress test REST APIs directly?
Yes. The
cy.request() command makes real HTTP requests to any URL — GET, POST, PUT, PATCH, DELETE — and gives you the response body, status code, headers, and duration to assert against. You do not need a browser open. This makes Cypress useful as a scriptable API testing client inside your existing test suite.What is the difference between cy.request() and cy.intercept() in Cypress?
cy.request() makes a direct HTTP call from your test — like calling an API from a script. cy.intercept() sits between your running frontend application and the network, letting you spy on, assert against, modify, or stub the requests your UI code makes. Use cy.request() to test the API itself; use cy.intercept() to test how your frontend handles API responses.Can you stub API responses in Cypress?
Yes.
cy.intercept() lets you replace any API response with fixture data, a hardcoded body, a specific status code, or a delayed response. This is useful for testing error states (500 responses), loading states (delayed responses), and edge cases (empty arrays, null fields) without needing your backend to reproduce those conditions.Can Cypress replace Postman for API testing?
For automated, integrated testing — yes, Cypress can cover what Postman covers in a CI pipeline. Postman is still better for manual API exploration, contract documentation, and testing APIs in isolation without a frontend. Cypress is better when you need to test how the API and the UI work together in the same test run.
How do you wait for an API call in Cypress?
Use
cy.intercept() with .as('aliasName') to name the request, then cy.wait('@aliasName') to pause the test until that request completes. This is more reliable than arbitrary cy.wait(2000) timeouts and gives you access to the full request and response object for assertions.Is Cypress API testing suitable for CI/CD pipelines?
Yes. Cypress runs headlessly in CI environments (GitHub Actions, CircleCI, Jenkins, GitLab CI) and produces JUnit XML reports, screenshots, and video recordings on failure. Both
cy.request() and cy.intercept() work identically in headless mode. Many teams run their Cypress API tests as a pre-deployment gate before promoting to production.What is the best way to learn Cypress API testing?
Start with
cy.request() — make a GET call, assert on the status and body. Then move to cy.intercept() by spying on a request your UI makes and asserting after cy.wait(). The Cypress documentation at example.cypress.io/commands/network-requests has runnable examples for every network command. From there, apply it to real project scenarios — that is where the skill solidifies.Learn by Doing. Prove by Doing. Get Hired.
Questions about API testing, QA workflows, or which track fits your goals? The Archi's Academy team works with developers at every level — reach out anytime.
Monday, Jan 18, 2021

