How To Use Cypress Intercept For Handling Network Requests

What Is Intercepting Network Requests?

Intercepting network requests involves capturing and analyzing the data exchanged between a client and server during network communication, typically focusing on HTTP requests and responses.

This process is useful in various scenarios:

• Debugging and troubleshooting network issues.
• Inspecting request and response payloads.
• Modifying requests in real-time.

By intercepting network requests, it’s possible to inspect and manipulate aspects of communication, such as headers, parameters, cookies, and response data. Interception usually involves placing a proxy between the client and server, which intercepts all network traffic, allowing for inspection and modification before the traffic reaches its intended destination.

In the diagram above, the client’s request to the server is intercepted by a proxy before reaching the server. The proxy can analyze and modify the request before forwarding it to the server and can also analyze and modify the server’s response before sending it back to the client.

Two commonly used tools for analyzing network traffic are:

• Wireshark: A free and open-source packet analyzer that captures and analyzes network traffic in real-time.
• tcpdump: A tool that captures and filters network traffic for various protocols, including TCP, UDP, and ICMP.

What Is Cypress Intercept?

Cypress intercept (cy.intercept()) is a feature in Cypress that allows testers to intercept and control HTTP requests and responses between an application and external services. It streamlines network testing by giving testers the ability to manipulate, modify, or stub these requests and responses directly within their tests.

Leveraging cy.intercept() can significantly enhance the effectiveness and reliability of your tests.

Here’s why incorporating Cypress intercept into your testing strategy is advantageous:

• Mocking API responses: This helps create custom responses to simulate different scenarios, such as error states, empty responses, or large datasets. By controlling the responses, you ensure that your application behaves correctly under different conditions.
• Stubbing network calls: This helps replace actual network requests with predefined responses, cy.intercept() speeds up test execution and isolates the component under test. This approach eliminates the need for a real backend, reduces test flakiness, and focuses on testing specific functionalities without interference from external services.
• Improve Test Reliability: This helps control network interactions and ensure your tests are not affected by external factors such as network delays or changes in the backend services. This leads to more stable and reliable tests.

Note: Intercept network requests with Cypress on the cloud grid. Try TestMu AI Today!

Wiring each cy.intercept() call and its assertions by hand adds up across a suite. KaneAI, TestMu AI's GenAI-native testing agent, authors those intercept-driven Cypress tests from a plain-English prompt and maintains them as the app changes.

• Natural-language authoring - describe a flow, including its network stubs, in plain English and KaneAI turns it into a runnable test.
• Self-healing - smart element detection updates locators when the UI changes, so small edits do not break working tests.
• Framework export - generated tests export to Selenium, Cypress, Playwright, or Appium, with no vendor lock-in.
• Multiple inputs - converts PRDs, Jira tickets, PDFs, recordings, and GitHub PRs into structured, executable test cases.
• Broad coverage - covers web and native iOS and Android, plus API, database, and network validation.
• Reusable modules - turn common flows into reusable blocks and track test history with rollback.

Read the KaneAI documentation to get started.

Using Cypress Intercept for Handling Network Requests

Cypress is a JavaScript-based end-to-end testing framework that simplifies writing, running, and debugging tests for web applications. It supports intercepting and stubbing network requests, allowing you to control server responses and make assertions about network requests during Cypress end-to-end testing.

Subscribe to LambbdaTest YouTube Channel to get more tutorials on Cypress automation and more.

The cy.intercept() command in Cypress lets you intercept network requests by providing a URL pattern and a callback function. This command intercepts all requests matching the pattern, allowing you to modify the request, return a response, or pass the request to the network.

Below are the methods you can use in Cypress to spy on and stub network requests and responses.

cy.intercept(url)
cy.intercept(method, url)
cy.intercept(routeMatcher)

Here’s a simple example of how you could use the Cypress intercept command to return a fake response for a certain request:

cy.intercept('/api/data', {
    method: 'GET'
    }).as('getData')
    .reply(200, {
       data: 'Test Data'
    });
     
     
    // ... Perform your test logic ...
    cy.wait('@getData')
    .its('response.body')
    .should('deep.equal', {
       data: 'Test Data'
});

In this example, the cy.intercept() command is used to intercept all GET requests to the /api/data endpoint. The .reply method is then used to return a mock response with a status code of 200 and a JSON body of { data: ‘Test Data’ }. After intercepting the request, the cy.wait() command ensures the request is completed, and the response body is asserted to match the expected value.

Before diving into the details of these methods, let’s first understand how the cy.intercept() method works.

How Does the cy.intercept() Method Work?

The cy.intercept() method in Cypress intercepts and modifies HTTP requests and responses made by the application during testing. This allows you to simulate different network scenarios and test your application’s behavior under various conditions. You can intercept requests to specific URLs or those made by specific methods (e.g., GET, POST).

In the diagram below, the cy.intercept() method intercepts the requests and responses made by the Application Under Test (AUT). This interception can be configured to target specific URLs or HTTP methods, allowing precise control over the network traffic during your tests.

The steps of the diagram are explained below:

• The client (browser) initiates a request to the server.
• The server receives the request and sends back a response.
• The client receives the response and handles it.

With Cypress intercept:

• Cypress intercepts the requests before it reaches the server.
• The test code can modify the request or the response, such as adding headers, delaying the response, or changing the status code.
• The test code returns a stubbed response that replaces the actual response from the server.
• The client receives the stubbed response and handles it as if it came from the server.

Once you receive the response, you can verify the stubbed response through assertions.

Now that you understand how cy.intercept() works, let’s explore the various ways to intercept network requests in Cypress.

Overriding an Existing Cypress Intercept

Overriding an existing Cypress intercept allows you to modify or cancel a network request intercept already defined in your test code. This can be useful when you want to change the behavior of an intercept, such as simulating a different server response or altering the request data.

The main difference between intercepting and overriding is that intercepting defines new intercepts, while overriding modifies existing ones.

The example below demonstrates how to use the Cypress intercept method to override an existing intercept and adjust your application’s behavior during testing.

describe.only('Override an existing intercept example', () => {
    beforeEach(() => {
      cy.intercept('GET', 'https://reqres.in/api/users').as('getUsers')
    })
   
   
    it('overrides the response of the /api/users request', () => {
      cy.visit('https://reqres.in/')
      cy.intercept('GET', 'https://reqres.in/api/users', (req) => {
        req.reply((res) => {
          res.send({
            data: [{ id: 1, email: 'test@test.com' }],
            page: 1,
            per_page: 1,
            total: 1,
            total_pages: 1
          })
        })
      }).as('getUsers')
   
   
      cy.wait('@getUsers').then((interception) => {
        expect(interception.response.body.data).to.have.length(1)
        expect(interception.response.body.data[0].email).to.eq('test@test.com')
      })
    })
   })

In this example, you first define an intercept for the GET /api/users request and give it an alias of getUsers. Then, in the test itself, you can override the same request by defining a new intercept with the same alias of getUsers.

In the new intercept, you use the req.reply() function to override the original request’s response and return a new response that includes a single user with an email of ‘test@test.com‘. Finally, you can use the cy.wait() command to wait for the getUsers alias to complete, and then we test the response to ensure it contains the expected data.

Result:

As you have already seen, Cypress intercept methods such as cy.intercept(), cy.wait(), and others help intercept and manipulate network requests. Additionally, other automation testing tools also enhance the ability to intercept and manage network requests effectively.

Some QA automation tools that can complement and extend the functionality of intercepting network requests include:

• Selenium: Selenium is a popular open-source framework for automating web application testing. While it does not have built-in capabilities for intercepting network requests, it can be integrated with other tools to achieve this functionality.
• Playwright: With Playwright, you can intercept network requests using the page.route() method. This method enables you to intercept requests and provide custom responses.
• Postman: Postman is a popular API development and testing tool that allows you to inspect and modify network requests. It provides a user-friendly interface and a wide range of features for API testing.
• Charles: Charles is a web debugging proxy tool used to inspect, debug, and modify network requests. It is commonly used by developers to troubleshoot issues with web applications and APIs.
• Fiddler: Fiddler is a web debugging proxy tool that allows you to inspect and modify network requests. It is widely utilized for QA automation.
• JMeter: JMeter is an open-source load testing tool that includes features for intercepting and modifying network requests. It is used for testing the performance of web applications and APIs.
• Burp Suite: Burp Suite is a powerful tool for testing web applications. It allows you to intercept and manipulate HTTP requests and responses, providing detailed insights into network traffic.
• SoapUI: SoapUI is an open-source tool for testing web services, including features for intercepting network requests. It is widely used for testing SOAP and REST APIs.

While traditional QA tools are essential for intercepting and analyzing network requests, QA teams can also leverage cloud-based platforms like TestMu AI for additional benefits.

TestMu AI is an AI-powered automation testing platform that offers a robust cloud infrastructure that enables you to run tests at scale across 3000+ browsers and operating system combinations without the need for physical hardware.

This platform helps scale testing efforts, execute tests concurrently, and integrate seamlessly with existing tools, enhancing your overall testing strategy.

How Do AI Agents Automate Network Request Interception?

AI coding agents can now perform the same interception cy.intercept() does, through a Model Context Protocol (MCP) server instead of a hand-written Cypress command. Microsoft's official Playwright MCP server exposes a tool called browser_route. An agent driving a browser through MCP calls browser_route with a URL pattern, and the server intercepts any matching request before it reaches the network, then fulfills it with a mocked status code, body, and headers, or forwards it with modified headers.

This mirrors the RouteMatcher and pattern-matching techniques already covered on this page. The mechanism is the same: match a request, then decide whether to fulfill it locally or forward it. The difference is who writes the matching logic. With cy.intercept(), a tester writes the pattern and the stub by hand. With an MCP-driven agent, a coding assistant can call browser_route directly while exploring an application and generate the mock on the fly.

The real limitation applies to both approaches. Per Playwright MCP's network mocking documentation, its origin restrictions are convenience guardrails and not a security boundary, and they do not affect redirects; mocking also holds only for the active browser session and needs explicit setup per test. An agent can generate a stub faster than a person, but it still needs the same precise URL matching this page teaches, or it risks intercepting the wrong request.

Wrapping up

Stubbing allows you to intercept network requests and replace them with predefined responses, avoiding the need to send the request over the network. However, stubbing can sometimes result in false positives, as the behavior of the stubbed requests may not truly represent actual network behavior, potentially leading to missed bugs or errors.

On the other hand, not using stubbing with Cypress intercept provides a more accurate representation of your application’s behavior by allowing real network requests. This approach offers greater confidence that your tests truly reflect how the application behaves in the real world.