# API Mocking
Source: https://interceptor-docs.requestly.com/api-mocking/api-mocking
## **Introduction to API Mocking**
This section introduces the concept of API mocking and explains how it can help developers and testers during the development process. API mocking is particularly useful for frontend developers, testers, and teams working in environments where backend services are unavailable or incomplete.
By the end of this section, you will have a clear understanding of API mocking and its benefits, along with links to detailed pages for each approach.
## What is API Mocking?
API mocking is the process of simulating API responses without relying on the actual backend server. It allows developers and testers to create mock responses to API calls, making development and testing faster, more flexible, and independent of backend availability.
By using API mocking, you can:
* Unblock frontend development when APIs are incomplete or unavailable.
* Test your application against different API responses (success, error, or edge cases).
* Simulate performance scenarios like delayed responses.
With **Requestly Interceptor**, you can easily create and manage API mocks to streamline your development workflow. Requestly Interceptor provides two approaches to mocking APIs:
### **Create Local API Mocks**
Using Requestly Interceptor’s **Modify Response** feature, you can easily create **Local API Mocks** to simulate API responses without hitting the actual server. This is perfect for testing and development when you need to work offline or want to simulate specific scenarios. You can create mocks for individual endpoints or use a recorded session from Requestly Interceptor to create mock responses in bulk.
For detailed instructions on setting up Local Mocks and Modify Response, visit our [Local Mocks Documentation](/api-mocking/create-local-api-mocks).
## Create Cloud Mocks
With **File Server**, you can upload or create files directly on Requestly Interceptor’s servers. These files can then be used as **redirect destinations** for any API request using Requestly Interceptor’s **Redirect Rule**. This allows you to simulate API responses effortlessly without relying on a live server.
Each mock file is accessible via a **dedicated URL**, making it easy to share across teams and environments. This approach is perfect for collaborative testing, automated workflows, and ensuring consistent API simulation throughout the development and testing lifecycle.
For step-by-step instructions on creating and managing Cloud Mocks, visit our [Cloud Mocks Documentation](/api-mocking/create-cloud-based-mocks).
# Create Cloud-based Mocks
Source: https://interceptor-docs.requestly.com/api-mocking/create-cloud-based-mocks
Learn how to create modify and manage mock files in requestly
Cloud-based mocks let you simulate API responses by hosting mock data online instead of running a local server. With Requestly Interceptor’s File Server, you can upload mock files like JSON or HTML and redirect real API requests to these files. It’s a fast, shareable, and reliable way to mock backend APIs for frontend development and testing in isolation.
## How to Create a Cloud-based Mock
To create a cloud mock, you’ll first create a file in File Server and then set up a Redirect Rule to serve it in place of a real API.
### Step 1: Create a File in Requestly Interceptor File Server
From the Requestly Interceptor Dashboard, go to the **Files** tab in the sidebar.
Choose **New File** to create one from scratch, or upload an existing JSON file.
Give it a descriptive name and fill in the following options:
* **Method**: HTTP method to match (GET, POST, etc.)
* **Status**: Response code (e.g. 200 OK)
* **Content Type**: e.g. `application/json`
* **Latency** *(optional)*: Simulate response delay
* **Endpoint**: Define a unique URL path
* **Response Body**: Add your mock JSON/text
* **Headers** *(optional)*: Add custom response headers
* **Password Protection** *(optional)*: Secure with a query param password
### Step 2: Redirect API Requests to File Server
Go to **HTTP Rules → + New Rule → Redirect Rule**.
Give your rule a clear name and optional description.
Define when the rule should trigger. Use filters like **URL Contains**, **Equals**, **Regex**, or **Advanced Filters**.
> 💡 Example:
>
> Match the bakery products API in the [Requestly Interceptor Playground:](https://requestly-playground.com/)
>
> [`https://rest.requestly-playground.com/api/products?searchJoin=and&with=type%3Bauthor&limit=30&language=en&search=type.slug:bakery%3Bstatus:publish`](https://rest.requestly-playground.com/api/products?searchJoin=and\&with=type%3Bauthor\&limit=30\&language=en\&search=type.slug:bakery%3Bstatus:publish)
Paste the File Server URL copied earlier. You can also select the file directly from File Server.
Click **Save** and toggle the rule **ON** to activate it.
# Create Local API Mocks
Source: https://interceptor-docs.requestly.com/api-mocking/create-local-api-mocks
Learn how to mock APIs locally with ease using Requestly Interceptor
## **Introduction**
Creating mock APIs locally with Requestly Interceptor is a powerful way to simulate server responses directly in your development environment. This feature is invaluable for developers looking to test features, handle edge cases, or debug applications without relying on live servers.
On this page, you'll see how to use Requestly Interceptor’s Modify API Response rule to mock API responses and create bulk mocks using recorded sessions, making your workflow faster and more efficient.
## **Steps to Create a Mock API Using the Modify Response Rule**
The **Modify API Response** rule allows you to intercept and alter API responses without needing changes on the server. It’s a powerful feature for testing, debugging, and mocking APIs during development.
This rule is available on both the **Requestly Interceptor desktop app** and the **browser extension**, giving you flexibility across environments.
To create a mock API, you can use this rule to intercept and return a static response for a specific request without sending it to the server.
Log in to your Requestly Interceptor account and navigate to the **HTTP** **Rules** section.
Here click on New rule and select **Modify API Response** as the rule type.
Set up your Modify API Response rule with the necessary configurations. We'll use [**Requestly Interceptor Playground**](https://www.requestly-playground.com/) as a demo for this \[example]\([https://app.requestly.io/rules#sharedList/320743d1f2eb488bb71047ae5501c7fc-Requestly](https://app.requestly.io/rules#sharedList/320743d1f2eb488bb71047ae5501c7fc-Requestly) Interceptor-Playground):
* **Source Condition**: Match [`https://mock.redq.io/api/products`](https://mock.redq.io/api/products) (using contains).
* **Response Status Code**: Set to `200`.
* **Response Body**: Provide a static JSON response
You can tick the “Server this response body without making call to the server” checkbox as the label suggests it will ensure you get the response locally without hitting your API server.
For a detailed breakdown of all available options, refer to the Modify API Response Rule page.
Save your rule and visit the [website](https://www.requestly-playground.com/) to test your mock api
## **Bulk API Mocking (Desktop App Only)**
Bulk API Mocking allows you to mock multiple API endpoints at once using recorded sessions. This helps replicate API responses for testing or development without hitting the live server.
### Recording a Session for Bulk API Mocking
**Record a Session**
If you haven’t already recorded a session, start by capturing the API requests and responses you want to mock using Requestly Interceptor’s interceptor and save it in a session, start by:
Open the Requestly Interceptor Desktop App and navigate to the **network traffic** tab on the left sidebar.
Click any of the `Connect Apps` buttons to open the **Connect Panel**, which displays all supported apps Requestly Interceptor can connect to.
Choose the application you want to connect to from the Connect Panel.
Perform the actions or user flows in your app or website to trigger the API requests you want to record. Requestly Interceptor will log all requests and responses automatically.
Once you've captured all the necessary API requests disconnect the app.
Click the **Save** button to store the recorded session. This saves all the captured API calls, allowing you to generate mock rules from them later.
### **Using Recorded Sessions for Bulk API Mocking**
Once you've recorded an API session, you can easily generate bulk mock rules based on the captured requests. This is a quick way to mock multiple API endpoints without manually configuring each one.
Navigate to the **Sessions** tab in the left sidebar of the Requestly Interceptor dashboard.
From the list of recorded sessions, select the session you want to use for mocking.
Click on **Create Mocks from This Session** in the top-right corner of the session page.
In the dropdown, select the type of resource you want to mock: **REST** or **GraphQL**. Then, click **Proceed**.
If you're mocking GraphQL requests, specify the keys (e.g., operationName) and values (e.g., ExampleQuery) to filter out the GraphQL requests you want to mock. This is useful to target specific GraphQL operations and ensure you're mocking only the relevant queries.
In the traffic table, choose the responses you want to create mocks for. You can select individual requests or multiple requests as needed.
Click on the **Create Mocks** button and select the matching condition from the dropdown:
* **Match Entire URL -** Matches the full URL, including protocol, host, path, and query parameters. eg: `https://mock.redq.io/api/products?limit=5` matches only if everything is identical.
* **Match Only Path -** Matches just the path, ignoring protocol, host, and query parameters. eg: `/api/products` matches regardless of `https://mock.redq.io` or `https://demo.redq.io`
* **Match Path and Query Params -** Matches the path and query parameters together. Example: `/v1/users?id=123` matches only if both are identical.
Click **Create Rules** to generate the mock rules. Requestly Interceptor will automatically create a collection of **Modify Response** rules, all enabled and ready to use.
To disable the mock you can either disable the whole collection or individual rules
These rules will intercept the API requests and return the mocked responses you configured, simplifying the process of mocking multiple APIs at once.
# Desktop App vs Browser Extension
Source: https://interceptor-docs.requestly.com/getting-started/difference-between-desktop-app-and-browser-extension
Compare the Requestly Desktop App and Browser Extension to choose the right HTTP interception setup.
Requestly offers two ways to intercept and modify HTTP traffic. Use the right one for your workflow, or use both in combination.
**Best for:** Intercepting and modifying traffic from inside the browser, fast setup, no configuration.
**Best for:** System-wide traffic interception, desktop apps, mobile devices, simulators, terminal, Node.js.
**Can't decide?** Both experiences sync your rules through Team Workspaces, so you can use whichever suits your current task.
***
## Feature Comparison
### Platform Availability
| Feature | Browser Extension | Desktop App |
| ---------------------- | ------------------------------------------------- | --------------------- |
| **Supported Browsers** | Chrome, Firefox, Edge, Brave, Arc, Vivaldi, Opera | N/A |
| **Supported OS** | Any OS with supported browser | Windows, macOS, Linux |
| **Installation** | Install from browser store | Download installer |
| **Launch Speed** | Fast (in browser) | Fast (standalone app) |
***
### Interception Scope
| Feature | Browser Extension | Desktop App |
| ------------------------------------ | ----------------- | ----------- |
| **Intercept browser traffic** | ✅ Supported | ✅ Supported |
| **Intercept desktop app traffic** | ❌ Not supported | ✅ Supported |
| **Intercept mobile devices** | ❌ Not supported | ✅ Supported |
| **Intercept iOS/Android simulators** | ❌ Not supported | ✅ Supported |
| **Intercept Node.js apps** | ❌ Not supported | ✅ Supported |
| **Intercept terminal/CLI traffic** | ❌ Not supported | ✅ Supported |
| **System-wide proxy** | ❌ Not supported | ✅ Supported |
***
### HTTP Rules
| Feature | Browser Extension | Desktop App |
| -------------------------------- | ----------------- | ----------- |
| **Modify Headers** | ✅ Supported | ✅ Supported |
| **Modify Request/Response Body** | ✅ Supported | ✅ Supported |
| **Modify Query Params** | ✅ Supported | ✅ Supported |
| **Redirect Rules** | ✅ Supported | ✅ Supported |
| **Replace Strings** | ✅ Supported | ✅ Supported |
| **Delay Requests** | ✅ Supported | ✅ Supported |
| **Cancel Requests** | ✅ Supported | ✅ Supported |
| **Insert Scripts** | ✅ Supported | ✅ Supported |
| **Map Local / Map Remote** | ✅ Supported | ✅ Supported |
| **Modify User Agent** | ✅ Supported | ✅ Supported |
***
### Network Inspection & Sessions
| Feature | Browser Extension | Desktop App |
| --------------------------- | ----------------- | ----------- |
| **Network Traffic Table** | ✅ (via DevTools) | ✅ Supported |
| **Session Recording** | ✅ Supported | ✅ Supported |
| **HAR File Import** | ✅ Supported | ✅ Supported |
| **Save logs to local file** | ❌ Not supported | ✅ Supported |
***
### Collaboration & Workspaces
| Feature | Browser Extension | Desktop App |
| ------------------- | ----------------- | ----------- |
| **Local Workspace** | ❌ Not available | ✅ Supported |
| **Team Workspaces** | ✅ Supported | ✅ Supported |
***
## Decision Guide
### Choose the **Browser Extension** if you:
* ✅ Only need to intercept traffic inside a browser
* ✅ Want a zero-configuration setup
* ✅ Debug web apps during frontend development
* ✅ Work mostly with JSON/HTML responses in the browser
Install and get started in under a minute
### Choose the **Desktop App** if you:
* ✅ Need to intercept traffic from mobile devices or simulators
* ✅ Debug native desktop applications
* ✅ Modify traffic from Node.js, terminal, or CLI tools
* ✅ Require a local workspace for offline work
* ✅ Want system-wide proxy control
Download and configure the full-featured desktop application
***
## Can I Use Both?
**Absolutely.** Many people use both:
* **Browser Extension** for quick in-browser debugging during frontend work
* **Desktop App** for mobile, native-app, and system-wide interception
Your rules sync across both when you use Team Workspaces, giving you flexibility to switch based on your current task.
***
## Need Help Choosing?
Choose a path and set up Requestly
Install and configure the browser extension
Install and configure the desktop app
Sync your work across platforms
# Download Requestly Interceptor
Source: https://interceptor-docs.requestly.com/getting-started/downloads
Requestly Interceptor is available across browsers and desktop platforms.
Choose the version that fits your workflow and start testing, debugging, or modifying network traffic instantly.
## Requestly Interceptor For Browsers
## Requestly Interceptor for Desktop
### **Install using Winget for Windows**
You can install Requestly Interceptor on Windows through Winget.\
Run this command in PowerShell or Command Prompt:
```bash theme={null}
winget install BrowserStackInc.Requestly
```
# Overview
Source: https://interceptor-docs.requestly.com/getting-started/overview
Start here to understand Requestly Interceptor, choose the right workflow, complete setup, and reach your first success quickly.
Requestly Interceptor helps you inspect and modify network traffic in real time. You can debug browser requests, intercept mobile and desktop app traffic, rewrite requests and responses, create mocks, and share debugging sessions with your team.
## Choose Your Path
Use the Browser Extension when you want to inspect and modify traffic in the browser.
Use the Desktop App when you need proxy-based interception for mobile apps, emulators, terminal tools, or system traffic.
Rewrite headers, bodies, query params, and responses without changing your application code.
Build reusable mock APIs and hosted responses for testing, demos, and collaboration.
## Understand The Product Areas
### Debugging & Interception
Use the [HTTP Interceptor](/interceptor/overview) when you need to inspect live traffic from a browser, desktop app, mobile device, emulator, terminal, or Node.js runtime.
### Modify Traffic
Use [HTTP Rules](/http-rules/overview) to modify headers, redirect requests, rewrite bodies, delay responses, inject scripts, or map requests to local and remote resources.
### Mock APIs & Responses
Use [API Mocking](/api-mocking/api-mocking) and [File Server](/mock-server/overview) to simulate backend behavior for development, testing, demos, and failure scenarios.
## Which Setup Should You Choose?
Choose the Browser Extension when:
* you only need browser-based workflows
* you want quick setup with no system proxy configuration
* you plan to inspect traffic, create rules, or work from the extension popup
Install the extension, understand the interface, and learn what it can do.
Choose the Desktop App when:
* you need to intercept mobile devices, emulators, or desktop apps
* you need system-wide or proxy-based interception
* you want richer network capture, HAR workflows, or advanced debugging
Install the desktop app and connect the right runtime for your workflow.
Still deciding? Read [how the Browser Extension differs from the Desktop App](/getting-started/difference-between-desktop-app-and-browser-extension).
## Recommended First Steps
If you only need browser-based traffic tools, start with the Browser Extension. If you need to intercept mobile apps, emulators, localhost traffic, or system-wide traffic, use the Desktop App.
Follow either the [Browser Extension setup](/getting-started/quick-start-guide/browser-extension-setup) or [Desktop App setup](/getting-started/quick-start-guide/desktop-app-setup) guide.
Pick one clear first task:
* [Inspect live traffic](/interceptor/overview)
* [Create your first traffic rule](/http-rules/rule-types)
* [Create your first mock](/mock-server/create/create-mock-api)
After your first successful task, explore sessions, collaboration, advanced rules, and mock scenarios.
## Common Journeys
Start with HTTP Rules if you need to change traffic without updating application code.
Start with HTTP Interceptor if you need to see live network traffic and trace issues.
Start with Sessions if you need reproducible bug reports or sharable network captures.
Start with File Server when you need stable responses for testing or demos.
## Next Steps
Get help with certificate, localhost, proxy, and device interception issues.
Automate Requestly Interceptor workflows programmatically.
# Browser Extension Setup
Source: https://interceptor-docs.requestly.com/getting-started/quick-start-guide/browser-extension-setup
The Requestly Interceptor Browser Extension is a lightweight yet powerful tool designed for developers working on **browser-based workflows**.
Requestly Interceptor’s browser extension is available for all major browsers including **Chrome, Firefox, Edge, Brave, Vivaldi, Arc**, and **Opera**.
With the Browser Extension, you can:
* Intercept and modify network requests directly in your browser
* Use the in-browser **Network Inspector**
* Capture rich debugging data (console logs, network logs, screen recordings)
* Connect with the Desktop App for enhanced capabilities like bulk mocking
Click here to download
the Requestly Interceptor extension for your favorite browser.
The extension uses your browser’s native network APIs, which means **no conflicts with VPNs or proxies**, and it runs seamlessly without installing any system-level tools.
### **Extension Popup**
You can open the Requestly Interceptor Extension popup by clicking its icon in the browser’s extensions list or top bar if pinned. We recommend pinning the Requestly Interceptor Extension for quick access.
The pop-up serves several purposes:
1. The first section includes the **Running Status toggle** to turn the extension on/off and an **Open App** button to launch the Requestly Interceptor app ([`https://app.requestly.io/`](https://app.requestly.io/)) for creating rules and using the web app.
2. The second section helps manage rules. Pinned rules and recently used rules appear for quick access. The **Executed Rules** tab shows rules applied to the current page. You can toggle rules using the toggle button and quickly create new ones using the button in the top-right corner.
3. The third section is for reporting webpage issues with detailed information, including screen recordings, console logs, network logs, local storage, and environment details. `Record this tab` starts recording, and `Watch last 5 min replay` shows recent activity, enabled via the **Configure** option. Data is stored locally and doesn’t affect performance unless shared.
You can click on `Record this tab` and check out the working of this feature quickly.
4. The last section, visible only if the Desktop App is running, lets you intercept browser traffic via the desktop app. Click **Connect** to link the browser profile to the app, useful for tasks like bulk mocking.
### **Web App**
The Web App can be accessed using the `Open App` button in the Extension Popup or by visiting [`https://app.requestly.io/`](https://app.requestly.io/) directly in your browser. The app is organised into main sections, represented by icons on the left sidebar:
1. **Home**: The homepage provides an overview of your resources and quick access to key actions.
2. **Network Inspector**: Similar to the browser’s dev tools, but with additional features.
3. **HTTP Rules**: Allows you to override network requests by modifying parts of the request or redirecting them, our most popular feature.
4. **Sessions**: Contains saved sessions from the Extension Popup discussed earlier.
5. **File Server**: Allows you to host custom files and mock endpoints in the cloud so you can test APIs and resource overrides with shareable URLs.
Each area has its own documentation, use the sidebar to explore Network Inspector, HTTP Rules, Sessions, and File Server.
**On Top (from left to right)**
1. **Workspace Selector** , Allows you to create a new workspace or switch between existing ones. Workspaces are where you group your work for specific teams or projects.
2. **Star** , A GitHub widget to star our repository and track Requestly Interceptor’s development.
3. **Search** , Helps you quickly navigate the app; search for an action like “Create New Workspace” and hit enter to quickly create new workspace.
4. **Ask AI** , An AI bot that can instantly assist with most queries. While our support team is prompt, AI provides even faster responses.
5. **Settings (Cog Icon)** , Opens the settings page, where you can configure Requestly Interceptor to suit your needs.
6. **Profile Picture Dropdown** , Displays your logged-in profile information and includes links to billing and logout.
**On the Bottom Left**
1. **Invite Button** , This lets you invite teammates to collaborate on Requestly Interceptor.
2. **Version Information** , Displays the current version of Requestly Interceptor, which can be helpful when communicating with our support team.
**On the Bottom Right**
1. **Chat Support Icon** , Located slightly above the API Documentation link, this connects you to our dedicated customer support team.
## When To Use The Browser Extension
Use the Browser Extension when you want to:
* inspect and modify traffic from websites and browser apps
* debug HTTP traffic without configuring a system proxy
* create HTTP Rules in a browser-first workflow
* capture browser-based debugging context quickly
Use the [Desktop App setup](/getting-started/quick-start-guide/desktop-app-setup) instead if you need mobile, emulator, terminal, Node.js, or system-wide interception.
## Recommended Next Steps
Choose a path and complete setup for interception-focused workflows.
Learn how interception works inside the browser extension.
Modify headers, redirect URLs, or rewrite responses without changing application code.
Check common extension and rules issues if traffic changes are not applying.
# Desktop App Setup
Source: https://interceptor-docs.requestly.com/getting-started/quick-start-guide/desktop-app-setup
The Requestly Interceptor Desktop App is a powerful **network interceptor** designed for developers. Whether you're building, testing, or debugging, it gives you the tools to intercept, inspect, and modify both **requests and responses** across your entire system
It goes beyond what browser-based tools can offer by supporting full system-level traffic interception, making it perfect for debugging desktop apps, mobile simulators, and more.
### **Install Desktop App**
The Desktop application offers additional features compared to the Browser Extension, as browser extensions are limited by security and other restrictions imposed by browsers. For example, while a browser extension cannot access local files, the Desktop app can. Here are some advantages of using the Desktop app:
1. It can access local files, enabling you to map files in mock responses.
2. The Desktop app can set up system-wide or application-level proxies, allowing it to intercept traffic from browsers, desktop applications, and mobile apps.
3. It can intercept traffic from Android/iOS simulators.
4. It can record an application's traffic and use it to create bulk mocks.
5. It allows you to import and view HAR files easily.
Click here to download the Desktop App for your OS.
## **Desktop App Interface**
The Desktop App interface closely mirrors the Web App interface, maintaining a consistent experience across platforms. However, there are some key differences from the Browser Extension:
1. **Network Traffic Tab** , Located on the left sidebar, this is the main feature of the Desktop App. It enables you to intercept traffic from desktop apps, Android simulators, iOS simulators, and even proxy traffic from mobile apps for detailed analysis.
2. **Proxy Server Indicator** , The `Proxy Server is listening` bar indicates that the proxy server is running on the Desktop App. It is used to intercept traffic from the various places mentioned above and display it in the Network Traffic table. Clicking the `Connect apps` button provides options to connect to browsers, desktop apps, mobile simulators, mobile apps, and more.
3. **Sessions** , Sessions in the Desktop App are recorded from the Network Traffic table, making them slightly different from the Web App. These sessions can be used for reference or to create bulk mocks.
4. Apart from these differences, the rest of the interface remains the same as the Web App.
The Desktop App’s additional capabilities make it ideal for scenarios requiring non-browser traffic interception and advanced mocking.
## When To Use The Desktop App
Use the Desktop App when you want to:
* intercept traffic from mobile apps, emulators, desktop apps, terminal tools, or Node.js
* capture system-wide traffic through a local proxy
* work with localhost traffic and advanced debugging scenarios
* record API sessions, import HAR files, or create mocks from captured traffic
If you only need browser-based interception and a lighter setup, start with the [Browser Extension setup](/getting-started/quick-start-guide/browser-extension-setup).
## Recommended Next Steps
Learn how interception works across browsers, devices, and runtimes.
Record requests and responses you can analyze, replay, or share.
Use captured traffic to modify, replay, or mock backend behavior.
Follow the interception troubleshooting path if setup is complete but traffic is missing.
# How to Log in to Requestly Interceptor with Your BrowserStack Account
Source: https://interceptor-docs.requestly.com/guides/can-i-log-in-to-requestly-using-my-browserstack-account
Navigate to the [Requestly Interceptor Dashboard](https://app.requestly.io/) in your browser.
Click the **Sign in** button on the top right corner of the page.
Enter the **email address associated with your BrowserStack account**
Depending on your status with BrowserStack, the next screen will vary:
* **If you already have a BrowserStack account**, you will be prompted to log in with it.\
If you're already logged into BrowserStack in your browser, you’ll be logged in to Requestly Interceptor automatically
* If you don’t have a BrowserStack account, you’ll be guided to create one.
# Automating API Tests with Requestly Interceptor's Collection Runner
Source: https://interceptor-docs.requestly.com/guides/community-content/using-collection-runner-in-requestly
Learn how to automate API testing workflows using Requestly Interceptor's Collection Runner feature - from setup to execution, with real examples using JSONPlaceholder.
## Introduction
"What if I could test all my APIs at once, like a chain reaction, without switching tabs or hitting Send repeatedly?"
If you've ever tested APIs manually, you know the pain:
1. Send a login request
2. Copy the token
3. Paste it into the next request
4. Then test one endpoint after another
It's repetitive and time-consuming, especially when you're testing a whole workflow like **Login → Create User → Fetch User → Delete User**.
That's where Requestly Interceptor's Collection Runner shines. In this guide, I'll walk you through how I explored the Collection Runner feature, how it simplifies API automation, and how you can start using it right away, even if you're completely new to automated API testing.
## Prerequisites
Before you begin, make sure you have:
* Requestly Interceptor app installed (desktop or browser extension)
* Basic understanding of APIs and HTTP methods
* Access to an API for testing (we'll use JSONPlaceholder in this tutorial)
* Familiarity with JavaScript (helpful but not required)
## What Is the Collection Runner?
The Collection Runner in Requestly Interceptor lets you execute multiple saved API requests sequentially, in a single automated flow.
Imagine chaining requests together: **Login → Create User → Fetch User → Delete User**
You can run them one after another, apply test scripts, reuse variables, and even debug results visually, all without writing a single line of backend automation code.
## Step-by-Step Guide
### Step 1: Setting Up Your First Collection
I started by opening the Requestly Interceptor app → going to **APIs** → **New** → and clicking **Collection**. You can also import a pre-existing API collection by clicking the **Import** button.
I named mine **User Management APIs**, because I wanted to simulate a typical CRUD workflow using JSONPlaceholder's `/users` endpoint.
Inside my collection, I added the following 4 requests:
1. `GET /users`, Fetch all users
2. `GET /users/1`, Get a specific user
3. `POST /users`, Create a new user
4. `DELETE /users/1`, Delete a user (mock)
Each request can include pre-request scripts, test scripts, and variables.
### Step 2: Using Pre-Request & Post-Response Scripts
You can use JavaScript to make your requests dynamic. Let's test a real example using JSONPlaceholder (a free mock API).
#### Pre-Request Script
```javascript theme={null}
const randomName = "User_" + (+new Date()).toString(36).slice(-5);
const randomEmail = randomName + "@example.com";
const randomPhone = Math.floor(Math.random() * 9000000000) + 1000000000;
rq.environment.set("name", randomName);
rq.environment.set("email", randomEmail);
rq.environment.set("phone_number", randomPhone);
```
#### Post-Request Script
```javascript theme={null}
rq.test("Status code is 201", () => {
rq.response.to.have.status(201);
});
rq.test("Request method is POST", () => {
rq.expect(rq.request.method).to.equal("POST");
});
rq.test("Response has valid JSON body", () => {
rq.response.to.have.jsonBody();
});
rq.test("Response body is JSON object", () => {
const parsed = JSON.parse(rq.response.body);
rq.expect(parsed).to.be.an("object").and.not.to.be.an("array");
});
```
These tests automatically validate the response when your collection runs. So now, after every run, I could instantly see if a request passed or failed, without manually checking the response body.
### Step 3: Running All Your Requests at Once
Once my collection was ready, I clicked the little **▶ Run** icon beside it (honestly, the most satisfying button).
This opened the Collection Runner, where I could configure:
* **Iterations**: How many times to repeat the run
* **Delay**: How long to wait between requests (useful if your server needs a breather)
* **Select data file**: Optional, useful if you want to pass different input sets for multiple runs
### Step 4: Reordering or Skipping Requests
Here's something I really liked, before running, I could reorder the requests or uncheck the ones I didn't want to include.
I dragged my "Delete User" request to the end (because, obviously, who deletes before testing?). That small UX detail made the workflow feel super flexible.
After setting everything up, I hit **Run Collection**, and boom! Requestly Interceptor started running all my requests in order, one after another, while I just watched it go.
### Step 5: Making It Dynamic with Variables & Environments
Hardcoding URLs and values works for one-time tests, but it quickly becomes a hassle when switching between environments like dev, staging, or prod.
That's where variables come in. Instead of writing full URLs, you can use placeholders like:
```
{{base_url}}/users
```
Then, in your **Variables** tab, define your base URL:
This way, you can easily switch between different environments without modifying each request individually.
### Step 6: The Results Dashboard
After running my JSONPlaceholder collection, Requestly Interceptor displayed a **Run Summary** that instantly made everything click.
It didn't just show "pass" or "fail", it broke everything down clearly:
* ✅ Number of passed tests
* ❌ Number of failed tests
* ⏱ Total execution time
* 💬 Average response time per request
Each request had its own section showing:
* HTTP method and endpoint (like `GET /users`, `POST /users`, `DELETE /users`)
* Response status (e.g., `200 OK`, `201 Created`)
* Test outcomes for each assertion you wrote
* Response body preview
Another really neat feature is the **History** tab in the top right corner. It automatically saves each run, so you can:
* Revisit old runs anytime
* Compare results between test iterations
* Track when something started failing
That means you can build up a timeline of test runs, perfect for debugging or regression tracking later on.
## What's Actually Happening Behind the Scenes
Here's a simple breakdown of what goes on under the hood when you click **Run**:
1. Variables like `{{base_url}}` get replaced
2. Pre-request scripts (if any) execute
3. The actual HTTP request is made
4. Post-response tests run automatically
5. Everything is logged in the Test results for you to analyze
It's basically like having a mini continuous testing pipeline, right inside Requestly Interceptor, but without the complexity of CI/CD setup.
## Examples
### Real-World Use Cases
After just one run, I could already see how useful this tool is for developers and testers alike:
**Regression Testing**: Run your full suite of APIs before every deployment.
**Chained Workflow Testing**: Simulate real user journeys (e.g., Create → Fetch → Update → Delete).
**Environment Switching**: Use variables to test across dev, staging, and prod instantly.
**QA Validation**: Automate repeated test cases with zero manual effort.
## Conclusion
The Collection Runner in Requestly Interceptor turns API testing from a manual chore into an effortless, automated workflow. Instead of juggling multiple tabs and copying data around, you can just run one collection and validate everything at once.
**Key Takeaways:**
* Collections let you organize and run multiple API requests in sequence
* Pre and post-request scripts enable dynamic testing and validation
* Variables make it easy to switch between environments
* The results dashboard provides instant visibility into test outcomes
* History tracking helps with debugging and regression analysis
It's like giving your APIs an autopilot mode. Try it once, and you'll never want to test manually again.
## Additional Resources
* [Requestly Interceptor Documentation, Collection Runner](https://docs.requestly.com)
* [Try Requestly Interceptor App](https://app.requestly.io)
* [GitHub Docs Repo](https://github.com/requestly/requestly-docs)
* [JSONPlaceholder Fake REST API](https://jsonplaceholder.typicode.com)
***
# Mastering Variables & Environments in Requestly Interceptor
Source: https://interceptor-docs.requestly.com/guides/community-content/variables-and-environments-in-requestly
A comprehensive hands-on guide to using Variables and Environments in Requestly Interceptor's API Client for seamless multi-environment API testing and development.
## Introduction
When I first opened Requestly Interceptor's API Client, I expected the usual, a request builder, a few tabs, maybe a scripting panel. What I didn't expect was how powerful and convenient their Variables and Environments system would be.
If you've ever switched between dev, staging, and production APIs and found yourself constantly rewriting URLs, headers, or tokens, this feature will feel like a lifesaver.
While working on a recent contribution to Requestly Interceptor, I got the chance to dive deep into Variables and Environments, and it turned out to be far more powerful than I expected. So in this article, I'm breaking down everything I learned in a simple, practical way.
Think of this as your shortcut to mastering variables, with practical steps and screenshots that you can apply immediately in your own setup.
## Prerequisites
Before you begin, make sure you have:
* Requestly Interceptor app installed (desktop or browser extension)
* Basic understanding of APIs and HTTP requests
* Access to multiple API environments (dev, staging, prod) - or you can use the free APIs mentioned in this guide
* Familiarity with API testing concepts
## The Problem: Managing Multiple Environments
Most teams today maintain multiple environments:
* Development
* Staging
* QA / Sandbox
* Production
Each environment has different:
* Base URLs
* Auth tokens
* Keys / secrets
* Custom headers
* Feature flags
Hardcoding these values inside every request is painful. Updating them manually is even worse.
Requestly Interceptor solves all of this with a simple idea:
Define variables once → use them everywhere.
You reference any variable using:
```
{{variable_name}}
```
For example:
```
https://{{base_url}}/users/{{user_id}}
```
## Step-by-Step Guide
### Step 1: Exploring Global Variables
Global variables are available everywhere, across all requests and environments. They are ideal for constants or secrets that don't change frequently. I used them for things like API keys, common headers, or service base URLs.
#### How to Create Global Variables
1. Open the **Environments** panel in the sidebar
2. Click **Global Variables**
3. Add key/value pairs like `api_key`, `base_url`, or `content_type`
The cool part?, Hovering on any `{{variable}}` in a request immediately shows the resolved value.
**Example Global Variables:**
```
api_key = your_secret_api_key
timeout = 5000
content_type = application/json
```
### Step 2: Creating Dev, Staging & Prod Environments
For my testing, I used three different APIs that all support the `/users` endpoint:
* **Development**, `https://jsonplaceholder.typicode.com`
* **Staging**, `https://jsonplaceholder.org`
* **Production**, `https://dummyjson.com`
#### Setting Up Environments
1. Open the **Environments** panel
2. Click **+ Create Environment**
3. Name your environment (e.g., "Development", "Staging", "Production")
4. Add variables specific to each environment
**Example Environment Configuration:**
**Development Environment:**
```
base_url = https://jsonplaceholder.typicode.com
environment = dev
```
**Staging Environment:**
```
base_url = https://jsonplaceholder.org
environment = staging
```
**Production Environment:**
```
base_url = https://dummyjson.com
environment = production
```
#### Switching Between Environments
Now I can fetch users from all three environments simply by switching the active environment, no URL editing needed.
1. Look for the environment dropdown (usually in the top-right)
2. Select your desired environment (Dev, Staging, or Prod)
3. All `{{base_url}}` references automatically update
### Step 3: Understanding Runtime Variables
By now, you've seen how Global and Environment variables help you standardize values across multiple requests. But what if you need something more temporary?
Maybe you're:
* Testing a login API and want to store a token for the next few calls
* Working across multiple workspaces and need a shared temporary value
* Debugging and want to store a session ID or a short-lived value
This is where Runtime Variables become incredibly useful.
Runtime variables are short-lived, local variables that exist only during your current session (unless you choose to make them persistent). They're perfect for storing things like:
* Temporary access tokens
* Session IDs
* Dynamic values generated during test runs
* One-time use values
#### How to Create Runtime Variables
1. Open **Runtime Variables** from the left sidebar
2. Click **+ Add More**
3. Add your variable fields (key and value)
That's it. The variable instantly becomes available across all requests.
**Example Usage:**
```javascript theme={null}
// In a post-response script :
const newtoken = JSON.parse(rq.response.body).token;
rq.environment.set("token", newtoken);
// Then use in subsequent requests
```
### Step 4: Collection & SubCollection Variables
Until now, we've looked at Global, Environment, and Runtime variables. These cover most cases, but what if you want variables that belong only to a specific group of requests?
For example:
* A group of API calls related to **Auth**
* A group of APIs for a specific **microservice**
* A test set for **payments**, **notifications**, etc.
This is exactly where **Collection and SubCollection Variables** shine.
#### Setting Up Collection Variables
1. Open the collection from the left sidebar
2. Click on **Collections**
3. Choose the collection you want
4. Switch to the **Variables** tab
5. Add your collection-specific variables
**Example Collection Variables:**
For an "Auth API" collection:
```
auth_endpoint = /api/v1/auth
token_expiry = 3600
refresh_endpoint = /api/v1/refresh
```
For a "Payment API" collection:
```
payment_endpoint = /api/v1/payments
currency = USD
payment_gateway = stripe
```
### Understanding Variable Precedence in Requestly Interceptor
Requestly Interceptor resolves variables based on the most specific scope first. If the same variable name exists in multiple places, this is the priority:
```
Environment → SubCollection → Collection → Global
```
**Meaning:**
1. **Environment variables** override everything
2. If not found, Requestly Interceptor checks **SubCollection**, then **Collection**
3. **Global variables** act as the final fallback
This makes configuration predictable and ensures environment-specific values always take priority without breaking your global or shared setup.
**Example Precedence:**
If you have `base_url` defined in all scopes:
* Global: `https://api.example.com`
* Collection: `https://api-v2.example.com`
* Environment (Production): `https://prod.example.com`
When Production environment is active, Requestly Interceptor will use: `https://prod.example.com`
## Examples
### Using Variables in API Requests
Once you've defined variables in Requestly Interceptor, whether global, environment, collection, or subcollection, you can reference them anywhere inside your API requests. This includes:
* URLs
* Headers
* Query parameters
* Request bodies
* Pre-request scripts
* Post-response scripts
This keeps your workspace clean, avoids repetition, and makes switching environments effortless.
#### Example 1: Using Variables in URLs
```
GET {{base_url}}/users/{{user_id}}
```
#### Example 2: Using Variables in Headers
```
Authorization: Bearer {{auth_token}}
Content-Type: {{content_type}}
X-API-Key: {{api_key}}
```
#### Example 3: Using Variables in Request Body
```json theme={null}
{
"email": "{{test_email}}",
"environment": "{{environment}}",
"api_version": "{{api_version}}"
}
```
#### Example 4: Dynamic Variables in Scripts
```javascript theme={null}
// Pre-request script
const timestamp = Date.now();
rq.environment.set("request_timestamp", timestamp);
// Use in request body or headers
// Body: { "timestamp": "{{request_timestamp}}" }
```
### Real-World Workflow Example
Here's a complete workflow using all variable types:
1. **Global Variables**: Store API key and common headers
2. **Environment Variables**: Define different `base_url` for dev/staging/prod
3. **Collection Variables**: Set endpoint paths for Auth collection
4. **Runtime Variables**: Store login token from response
5. **Make Authenticated Requests**: Use stored token in headers
```javascript theme={null}
// Step 1: Login Request
POST {{base_url}}{{auth_endpoint}}/login
// Step 2: Store token (post-response script)
const token = JSON.parse(rq.response.body).access_token;
rq.environment.set("auth_token", token);
// Step 3: Use token in subsequent requests
GET {{base_url}}/users/me
Headers: Authorization: Bearer {{auth_token}}
```
## Conclusion
After working with Requestly Interceptor's Variables & Environments, it's clear how much they simplify everyday API work. No more editing URLs or tokens by hand, no more messy requests, and no more switching values manually across environments.
**Key Takeaways:**
* **Global Variables**: Use for constants shared across all requests
* **Environment Variables**: Essential for managing multiple deployment environments
* **Runtime Variables**: Perfect for temporary, session-based values
* **Collection Variables**: Organize variables by feature or service
* **Variable Precedence**: Environment → SubCollection → Collection → Global
Everything becomes cleaner, faster, and far easier to manage, whether you're a backend developer, tester, or someone who works with multiple APIs.
Once you start using variables properly, your entire workflow becomes smoother and more organized. It's a small feature that makes a big difference, and honestly, it's hard to work without it once you get used to it.
## Additional Resources
* [Try Requestly Interceptor App](https://app.requestly.io)
* [Requestly Interceptor Documentation, Environment and Variables](https://docs.requestly.com)
* [JSONPlaceholder Fake REST API](https://jsonplaceholder.typicode.com)
* [DummyJSON API](https://dummyjson.com)
* [Join Requestly Interceptor Discord Community](https://rqst.ly/join-community)
***
**Have questions about variables or want to share your setup?** Join the [Requestly Interceptor community](https://rqst.ly/join-community) or reach out at [contact@requestly.io](mailto:contact@requestly.io)
# Disable Rule Application Status Widget
Source: https://interceptor-docs.requestly.com/guides/disable-rule-application-status-widget
Hide the on-screen widget that appears when a rule is applied by turning it off in the settings.
**Navigate to the Requestly Interceptor Settings page,** Open the Requestly Interceptor extension and click on the **Settings** tab in the left sidebar.
In the Global Settings menu, locate the **Show widget when rule is applied** section.
Click the toggle to disable the widget. This will stop the visual indicator from showing when rules are applied.
# Disable Rules Syncing in Requestly Interceptor
Source: https://interceptor-docs.requestly.com/guides/disable-rules-syncing
You can stop your rules from syncing across devices anytime by turning off the sync feature in Requestly Interceptor settings.
**Navigate to the Requestly Interceptor Settings page**\
Open the Requestly Interceptor extension and click on the **Settings** tab in the left sidebar.
In the Global Settings menu, locate the **Enable Syncing** section.
**Turn off syncing to keep rules local**\
Click the toggle to disable syncing. This will stop your rules from syncing across other devices.
# How to avoid intercepting certain domains
Source: https://interceptor-docs.requestly.com/guides/how-to-avoid-intercepting-certain-domains-on-the-desktop-app
Depending on from where you intend to intercept your requests there are multiple ways of achieving this
## Existing browser profile
You can already define a blocklist - domains that remain unaffected by the Requestly Interceptor extension inside the global settings of the webapp
If you have the Requestly Interceptor extension installed inside your browser, you can connect that browser easily to the desktop app using the `Connect To Desktop App` button in the extension popup
***
While establishing this connection, the extension makes sure that the domains from the blocklist are not affected by the proxy settings and hence do not get affected by the rules on the desktop app either.
## System wide proxy
When setting the system wide proxy you can also define a bypass list. The steps for this differs based on the operating system that you use.
On MacOS, Open `Settings` and navigate to the details of the `Wifi` that you are connected to.
In the proxy settings, you can define a comma separated bypass list that makes sure that requests matching these entries aren’t affected by the systemwide proxy settings
# How to conditionally fail requests based on request counts
Source: https://interceptor-docs.requestly.com/guides/how-to-conditionally-fail-requests-based-on-request-counts
Simulate a failed response on the first request and a successful one on subsequent attempts using [shared state](/http-rules/advanced-usage/shared-state) in Requestly Interceptor.
`$sharedState` is only available in extension versions > v24.8.13 and desktop app versions > v1.7.1.
### Steps to conditionally fail requests are:
Open Requestly Interceptor and create a new **Modify Response** rule.
Choose the **Dynamic JavaScript** option to write custom logic for the response.
Use the following code to fail the first request and let others succeed:
```javascript theme={null}
function modifyResponse(args) {
const {
method, url, response, responseType,
requestHeaders, requestData, responseJSON
} = args;
// Get the current count or start from 0
let count = $sharedState.count ?? 0;
count++;
$sharedState.count = count;
// Fail only the first request
if (count === 1) {
return null;
}
// Allow all subsequent requests to succeed
return response;
}
```
# How to Modify Cookies Using Requestly Interceptor
Source: https://interceptor-docs.requestly.com/guides/how-to-modify-cookies-using-requestly
Modifying cookies is useful when you're testing authentication flows, simulating different user states, or tweaking behavior without changing backend code. Requestly Interceptor makes this easy by letting you **intercept HTTP requests/responses** and **manipulate cookies** on the fly.
## Use Cases
* Testing login/logout behavior
* A/B testing variants
* Simulating admin/user roles
* Bypassing feature flags
## Modify Cookies in Requestly Interceptor
This is useful for **sending a custom cookie value** to the server.
Cookies are sent as a single string in the `Cookie` header, separated by semicolons.
Go to the **HTTP Rules** section, click on `+ New Rule` , and select `Modify Headers` from the list of options.
Give your rule a clear name like **Set Custom Cookie**. Optionally, add a short description so you can easily identify its purpose later.
Define where the rule should be applied by specifying criteria such as **URL**, **Host**, or **Path**. You can choose from options like **Regex**, **Contains**, **Wildcard**, or **Equals**, or use **Advance Filters** for more precise conditions.
For more details on source conditions, [**read this guide**.](/http-rules/advanced-usage/advance-targeting)
In the **Modification Type**, select **Request Headers** since we're modifying outgoing request headers.\
Under the **Request Headers** tab, click **Add Header** and set the following:
* **Action**: Add or Override
* **Header Name**: `Cookie`
* **Value**: `username=John Doe; expires=Thu, 18 Dec 2013 12:00:00 UTC`
This tells the browser to attach the specified cookie string in all matching requests.
Click **Save** to store the rule. After saving, make sure to **toggle it ON** to activate it.
This is useful to **change or inject cookies** coming from the server (e.g., simulate logged-in state).
Response Headers modification done by Requestly Interceptor are not visible in Browsers devtool but they are actually modified
Go to the **HTTP Rules** section, click `+ New Rule`, and choose **Modify Headers** from the list.
Give your rule a meaningful name like **Override Set-Cookie**.\
Add a short description to clarify that this rule modifies cookies sent from the server, useful for simulating logged-in sessions or testing different cookie values
Define where the rule should be applied by specifying criteria such as **URL**, **Host**, or **Path**. You can choose from options like **Regex**, **Contains**, **Wildcard**, or **Equals**, or use **Advance Filters** for more precise conditions.
For more details on source conditions, [**read this guide**.](/http-rules/advanced-usage/advance-targeting)
Choose **Response Headers** under **Modification Type**, since we're altering headers coming from the server.
Then under the **Response Headers** tab:
* **Action**: Modify
* **Header Name**: `Set-Cookie`
* **Value**: `username=John Doe; expires=Thu, 18 Dec 2013 12:00:00 UTC`
This will override the original `Set-Cookie` header sent by the server and inject your custom value instead.
Click **Save** to store your rule and **toggle it ON** to enable it.
Use `document.cookie` in the DevTools Console to check current cookies, or inspect request headers in the **Network tab**.
# Manually Update the Requestly Interceptor Chrome Extension
Source: https://interceptor-docs.requestly.com/guides/how-to-update-requestly-extension-manually
If Chrome hasn't auto-updated Requestly Interceptor yet, here's how to force the latest version instantly.
By default, Chrome automatically updates extensions when a new version is published to the Chrome Web Store. However, this process can take anywhere from a few hours to a couple of days.
If you want to update the Requestly Interceptor extension immediately, follow these steps:
Go to your Chrome browser and type `chrome://extensions/` in the address bar. Hit Enter.
In the top-right corner of the Extensions page, toggle on **Developer mode**.
Use the search bar at the top to search for “Requestly Interceptor.”
On the Requestly Interceptor extension card, click the **Update** button. Chrome will fetch and install the latest version.
# How to Use Requestly Interceptor Extension in BrowserStack Live
Source: https://interceptor-docs.requestly.com/guides/how-to-use-requestly-extension-in-browserstack-live
BrowserStack Live allows you to test websites on real browsers and operating systems. With **Requestly Interceptor**, you can modify network requests, mock APIs, redirect URLs, inject scripts, and debug your application directly inside your live sessions.
You can use Requestly Interceptor in BrowserStack Live in two ways:
1. **Preload the Requestly Interceptor extension** (recommended)
2. **Manually install the extension** inside the browser session
## Preloading the Requestly Interceptor Extension (Recommended)
BrowserStack allows certain extensions to be preloaded so they are automatically available in every new session. This is the fastest and most reliable way to use Requestly Interceptor in Live.
### Steps to Preload Requestly Interceptor
**Log in** to your BrowserStack **[Live dashboard](https://live.browserstack.com/dashboard)**.
Click the **Extensions** button next to the bookmark icon in the URL bar.
The **Extensions window** opens with the **Requestly Interceptor extension already added** by default. Enable the extension using the toggle switch.
Start a Live session by selecting a supported **OS** and **browser combination**. Requestly Interceptor loads automatically inside the browser.
### Supported OS & Browsers for Preloading
Preloading is supported only in **desktop sessions**.
| Operating System | Supported Browsers |
| ---------------- | -------------------------------- |
| **Windows** | Chrome (up to version 142), Edge |
| **macOS** | Chrome (up to version 142), Edge |
> **Note:** Firefox does not support preloading extensions. You can still install Requestly Interceptor manually during your session.
## Manually Installing Requestly Interceptor in BrowserStack Live
If your browser or session does not support preloading, you can manually install Requestly Interceptor inside the Live session.
### Chrome / Edge
Start a Live session using **Chrome** or **Edge**.
Open the **Chrome Web Store**.
Search for **Requestly Interceptor**.
Click **Add to Chrome** / **Add to Edge**.
The extension is now available in the browser.
### Firefox
For Firefox users, Requestly Interceptor can be installed through the Requestly Interceptor download page.
Start a Live session using **Firefox**.
Visit the Requestly Interceptor download page: **[https://requestly.in/downloads](https://requestly.in/downloads)**
Download the **Requestly Interceptor Firefox (.xpi) extension**.
When prompted, approve the installation.
Requestly Interceptor is now available inside the browser.
# Use Shared State to Aggregate Data Across Rules
Source: https://interceptor-docs.requestly.com/guides/how-to-use-shared-state-to-aggregate-data-and-use-across-requestly-rules
You can store response data from one API call and use it in the request body of another. This is done using `$sharedState`, allowing seamless data sharing between Modify Response and Modify Request rules
`$sharedState` is only available in extension versions **> v24.8.13** and desktop app versions **> v1.7.1**.
### Aggregate Data from API Response
Open Requestly Interceptor and create a new [Modify Response](/http-rules/rule-types/modify-response-body) rule.
Choose **Dynamic JavaScript Modification** in the rule options
Use the following code to store response values like `products` and `currency`:
```javascript theme={null}
function modifyResponse(args) {
const { method, url, response, responseType, requestHeaders, requestData, responseJSON } = args;
// Extract data from response
const productList = responseJSON.products;
const currency = responseJSON.currency;
// Store in shared state
$sharedState.productList = productList;
$sharedState.currency = currency;
return response;
}
```
## **Use Aggregated Data in Request Body**
Create a new Modify Request Body rule in Requestly Interceptor.
Select the **Dynamic Modification** option.
**Inject the stored products and currency into your outgoing request**\
Here’s the code to include the previously saved data:
```javascript theme={null}
function modifyRequestBody(args) {
const { method, url, body, bodyAsJson } = args;
// Retrieve shared state values
const products = $sharedState.productList;
const currency = $sharedState.currency;
// Inject into request body
return {
...bodyAsJson,
products,
currency
};
}
```
# Intercept & Modify Network Requests in Web Automation (Selenium, Playwright, etc.)
Source: https://interceptor-docs.requestly.com/guides/intercepting-and-modifying-network-requests-in-web-automation-frameworks-like-selenium-and-playwright
**Requestly Interceptor** is a powerful browser extension that allows developers and QAs to intercept and modify HTTP requests. It offers features like:
* HTTP header modifications
* URL redirects
* Request and response body overrides
* Injecting custom CSS and JavaScript
In this guide, we’ll show you how to use Requestly Interceptor in an end-to-end (E2E) web testing framework.
### What You Can Do with Requestly Interceptor in Automation For now
There are **2 main ways** to use Requestly Interceptor in an automation environment:
We also offer an NPM package, **@requestly/rq-automation**, to make this easier.\
`Learn more →`
1. **Header Modifications**, quick, one-off rules (no API key required)
2. **Import Rules via API Key**, for predefined rules managed from your Requestly Interceptor account
### Header Modifications
If you only need simple header overrides (without API key), like adding or removing request/response headers, refer to this page:\
[Modify HTTP Headers →](/guides/modify-http-headers-in-web-automation-using-requestly)
### Import Rules via API Key
Start by creating the rules you want to use in a new team workspace. Once the rules are set up, request an API key for the workspace by filling out [**this form**](https://app.formbricks.com/s/clryn62s316gjdeho9j03t7oa). The rules in this workspace will be automatically fetched and applied during the end-to-end (E2E) testing in the browser instance.
Download [**Chrome for Testing**](https://googlechromelabs.github.io/chrome-for-testing), the automation-friendly version of Chrome.
**Why Chrome for Testing?**
Starting with Chrome 137, official Chrome builds **no longer support the** `--load-extension` flag due to security concerns. [`There commit →`](https://chromium.googlesource.com/chromium/src/+/290ed8046692651ce76088914750cb659b65fb17%5E%21/chrome/browser/extensions/extension_service.cc)
To load extensions in automation tools (Selenium, Playwright, Puppeteer, etc.), you **must use Chrome for Testing** or Chromium.
Regular Chrome will block extension loading via automation. Use Chrome for Testing to avoid breakages and ensure compatibility.
```bash theme={null}
npm install selenium-webdriver
```
```javascript theme={null}
npm install playwright
```
```javascript theme={null}
npm install puppeteer
```
If you're using our NPM package, you don’t need to download it. Simply call the function `getExtension()`.
Download the CRX file of the [**Requestly Interceptor Extension**](https://requestly.com/downloads/crx/).
Use your automation tool’s configuration options to:
* Set the path to Chrome for Testing binary
* Add the Requestly Interceptor CRX extension
For JavaScript, use our NPM package `@requestly/rq-automation`.\
`Learn more →`
For Javascript ( Node.js )
```javascript theme={null}
const { Builder } = require("selenium-webdriver");
const chrome = require("selenium-webdriver/chrome");
const path = require("path");
const extensionPath = path.resolve(__dirname, 'requestly.crx'); // unpacked CRX folder
// IF Using Our NPM Package @requestly/rq-automation
// const { getExtension } = require("@requestly/rq-automation");
// const extensionPath = getExtension("crx");
// -----
const options = new chrome.Options();
options.setChromeBinaryPath("/Path/to/chrome-for-testing");
options.addExtensions(extensionPath);
const driver = await new Builder()
.forBrowser("chrome")
.setChromeOptions(options)
.build();
// Now use driver.get() to navigate as needed...
```
For Python
```python theme={null}
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
chrome_options = Options()
chrome_options.binary_location = "/Path/to/chrome-for-testing"
chrome_options.add_extension("/path/to/requestly.crx")
driver = webdriver.Chrome(options=chrome_options)
# driver.get(...) to open pages
```
For Java
```java theme={null}
ChromeOptions options = new ChromeOptions();
options.setBinary("/Path/to/chrome-for-testing");
options.addExtensions(new File("/path/to/requestly.crx"));
WebDriver driver = new ChromeDriver(options);
// driver.get(...) to open pages
```
For Javascript ( Node.js )
```javascript theme={null}
const { chromium } = require('playwright');
const extensionPath = require('path').resolve(__dirname, 'requestly'); // unpacked CRX folder
// IF Using Our NPM Package @requestly/rq-automation
// const { getExtension } = require("@requestly/rq-automation");
// const extensionPath = getExtension("unpacked");
// -----
const userDataDir = './user-data';
const context = await chromium.launchPersistentContext(userDataDir, {
channel: "chromium", // Enable extensions
headless: false, // Set to true only if you handle '--headless=new'
args: [
`--disable-extensions-except=${extensionPath}`,
`--load-extension=${extensionPath}`,
],
});
const page = await context.newPage();
// Use page.goto(...) next
```
For Python
```python theme={null}
from playwright.sync_api import sync_playwright
path_to_ext = "./requestly" # path to unpacked CRX folder
user_data_dir = "/tmp/user-data-dir"
with sync_playwright() as pw:
context = pw.chromium.launch_persistent_context(
user_data_dir,
channel="chromium",
headless=False,
args=[
f"--disable-extensions-except={path_to_ext}",
f"--load-extension={path_to_ext}"
]
)
page = context.new_page()
# use page.goto(...)
context.close()
```
For Javascript ( Node.js )
```javascript theme={null}
const puppeteer = require('puppeteer');
const path = require('path');
const extensionPath = path.resolve(__dirname, 'requestly');
// IF Using Our NPM Package @requestly/rq-automation
// const { getExtension } = require("@requestly/rq-automation");
// const extensionPath = getExtension("unpacked");
// -----
const browser = await puppeteer.launch({
executablePath: "/Path/to/chrome-for-testing",
headless: false,
args: [
`--disable-extensions-except=${extensionPath}`,
`--load-extension=${extensionPath}`
]
});
const page = await browser.newPage();
// page.goto(...) next
```
When Chrome installs the Requestly Interceptor extension, it may open a "welcome" (post-install) tab that interrupts automation. You can close this tab programmatically:
```javascript theme={null}
// give Chrome a moment for any stray tabs
await driver.sleep(500);
// close any “welcome” tab if still present
const handles = await driver.getAllWindowHandles();
const mainHandle = handles[0];
for (const handle of handles.slice(1)) {
await driver.switchTo().window(handle);
await driver.close();
}
await driver.switchTo().window(mainHandle);
```
```javascript theme={null}
const page = await context.newPage(); // Assume the first one is your primary page
await page.waitForTimeout(2000);
// Get all open pages in the current context
const pages = context.pages();
// Iterate through the pages and close any that are not the primary 'page' object
for (const openedPage of pages) {
if (openedPage !== page) {
console.log(`Closing extraneous page: ${openedPage.url()}`);
await openedPage.close();
}
}
// page.goto(...) next
```
```javascript theme={null}
const pages = await browser.pages();
const page = pages[0]; // Assume the first one is your primary page
await page.waitForTimeout(2000);
// Close all other pages except the primary one
for (const openedPage of pages) {
if (openedPage !== page) {
console.log(`Closing extraneous page: ${openedPage.url()}`);
await openedPage.close();
}
}
```
```javascript theme={null}
const { closeWelcomePage } = require("@requestly/rq-automation");
await closeWelcomePage(driver);
```
Visit the following URL in your automated browser to import all active rules from your account:
```java theme={null}
https://app.requestly.io/automation?apiKey=
```
```javascript theme={null}
const { importRules } = require("@requestly/rq-automation");
// this will return an URL to import rules
importRules("YOUR_API_KEY")
// https://app.requestly.io/automation?apiKey=
```
# How to Modify HTML Document using Modify API Response Rule
Source: https://interceptor-docs.requestly.com/guides/modify-html-document-using-modify-api-response-rule
Requestly Interceptor's **Modify API Response** rule lets you **directly modify the response of top-level HTML documents**. This feature is **only available for desktop app** but you can use file server and redirect rule as a workaround for most use cases.
**Click here to download** the Desktop App for your OS.
Navigate to the HTTP Rules section in the Requestly Interceptor app. Click `+ New Rule` and choose the `Modify API Response` option.
Provide a **descriptive name** for the rule to keep your setup organized. Optionally, add a **brief description** explaining its purpose for easier identification later.
In the Resource Type choose HTML/ JS/ CSS
Define the criteria for the rule to be applied, such as **URL**, **Host**, or **Path**. Choose from **Regex**, **Contains**, **Wildcard**, or **Equals**, or use **Advance Filters** for more precise conditions.
For more detailed guidance, refer to [**Source Conditions Guide**](/http-rules/advanced-usage/source-conditions).
Modify the status code of the response using the dropdown menu. Choose from:
* `2XX` for successful responses
* `4XX` for client errors
* `5XX` for server errors
If left empty, the original status code remains unchanged.
Choose one of the following methods to modify the response data:
* **Static Response Modification**: Input a static value as the response body.
* **Dynamic** **Modification Script (JavaScript)**: Use JavaScript to modify responses dynamically. The script provides access to parameters like:
* `method`: HTTP Method (GET, POST, etc.)
* `url`: Full URL of the request
* `response`: Original response body (string)
* `responseType`: Content type of the original response
* `requestHeaders`: Headers sent with the request
* `responseJSON`: Original response parsed as a JSON object
Click **Save** to store the rule and toggle it **ON**. This will apply the rule to the defined source conditions.
# Modify HTTP Headers in Web Automation Using Requestly Interceptor
Source: https://interceptor-docs.requestly.com/guides/modify-http-headers-in-web-automation-using-requestly
In this guide, we’ll walk through how to integrate Requestly Interceptor into any browser-based automation framework (Selenium, Playwright, Puppeteer, etc.) to programmatically modify request and response headers.
### Steps to Use Requestly Interceptor for Header Modification in Automation
We also offer an NPM package, **@requestly/rq-automation**, to make this easier.\
`Learn more →`
Download [**Chrome for Testing**](https://googlechromelabs.github.io/chrome-for-testing), the automation-friendly version of Chrome.
**Why Chrome for Testing?**
Starting with Chrome 137, official Chrome builds **no longer support the** `--load-extension` flag due to security concerns. [`There commit →`](https://chromium.googlesource.com/chromium/src/+/290ed8046692651ce76088914750cb659b65fb17%5E%21/chrome/browser/extensions/extension_service.cc)
To load extensions in automation tools (Selenium, Playwright, Puppeteer, etc.), you **must use Chrome for Testing** or Chromium.
Regular Chrome will block extension loading via automation. Use Chrome for Testing to avoid breakages and ensure compatibility.
```bash theme={null}
npm install selenium-webdriver
```
```bash theme={null}
npm install playwright
```
```bash theme={null}
npm install puppeteer
```
If you're using our NPM package, you don’t need to download it. Simply call the function `getExtension()`.
Download the CRX file of the [Requestly Interceptor Extension](https://requestly.com/downloads/crx/).
Use your automation tool’s configuration options to:
* Set the path to Chrome for Testing binary
* Add the Requestly Interceptor CRX extension
For JavaScript, use our NPM package `@requestly/rq-automation`.\
`Learn more →`
For Javascript ( Node.js )
```javascript theme={null}
const { Builder } = require("selenium-webdriver");
const chrome = require("selenium-webdriver/chrome");
const path = require("path");
const extensionPath = path.resolve(__dirname, 'requestly.crx'); // unpacked CRX folder
// IF Using Our NPM Package @requestly/rq-automation
// const { getExtension } = require("@requestly/rq-automation");
// const extensionPath = getExtension("crx");
// -----
const options = new chrome.Options();
options.setChromeBinaryPath("/Path/to/chrome-for-testing");
options.addExtensions(extensionPath);
const driver = await new Builder()
.forBrowser("chrome")
.setChromeOptions(options)
.build();
// Now use driver.get() to navigate as needed...
```
For Python
```python theme={null}
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
chrome_options = Options()
chrome_options.binary_location = "/Path/to/chrome-for-testing"
chrome_options.add_extension("/path/to/requestly.crx")
driver = webdriver.Chrome(options=chrome_options)
# driver.get(...) to open pages
```
For Java
```java theme={null}
ChromeOptions options = new ChromeOptions();
options.setBinary("/Path/to/chrome-for-testing");
options.addExtensions(new File("/path/to/requestly.crx"));
WebDriver driver = new ChromeDriver(options);
// driver.get(...) to open pages
```
For Javascript ( Node.js )
```javascript theme={null}
const { chromium } = require('playwright');
const extensionPath = require('path').resolve(__dirname, 'requestly'); // unpacked CRX folder
// IF Using Our NPM Package @requestly/rq-automation
// const { getExtension } = require("@requestly/rq-automation");
// const extensionPath = getExtension("unpacked");
// -----
const userDataDir = './user-data';
const context = await chromium.launchPersistentContext(userDataDir, {
channel: "chromium", // Enable extensions
headless: false, // Set to true only if you handle '--headless=new'
args: [
`--disable-extensions-except=${extensionPath}`,
`--load-extension=${extensionPath}`,
],
});
const page = await context.newPage();
// Use page.goto(...) next
```
For Python
```python theme={null}
from playwright.sync_api import sync_playwright
path_to_ext = "./requestly" # path to unpacked CRX folder
user_data_dir = "/tmp/user-data-dir"
with sync_playwright() as pw:
context = pw.chromium.launch_persistent_context(
user_data_dir,
channel="chromium",
headless=False,
args=[
f"--disable-extensions-except={path_to_ext}",
f"--load-extension={path_to_ext}"
]
)
page = context.new_page()
# use page.goto(...)
context.close()
```
For Javascript ( Node.js )
```javascript theme={null}
const puppeteer = require('puppeteer');
const path = require('path');
const extensionPath = path.resolve(__dirname, 'requestly');
// IF Using Our NPM Package @requestly/rq-automation
// const { getExtension } = require("@requestly/rq-automation");
// const extensionPath = getExtension("unpacked");
// -----
const browser = await puppeteer.launch({
executablePath: "/Path/to/chrome-for-testing",
headless: false,
args: [
`--disable-extensions-except=${extensionPath}`,
`--load-extension=${extensionPath}`
]
});
const page = await browser.newPage();
// page.goto(...) next
```
When Chrome installs the Requestly Interceptor extension, it may open a "welcome" (post-install) tab that interrupts automation. You can close this tab programmatically:
```javascript theme={null}
// give Chrome a moment for any stray tabs
await driver.sleep(500);
// close any “welcome” tab if still present
const handles = await driver.getAllWindowHandles();
const mainHandle = handles[0];
for (const handle of handles.slice(1)) {
await driver.switchTo().window(handle);
await driver.close();
}
await driver.switchTo().window(mainHandle)
```
```javascript theme={null}
const page = await context.newPage(); // Assume the first one is your primary page
await page.waitForTimeout(2000);
// Get all open pages in the current context
const pages = context.pages();
// Iterate through the pages and close any that are not the primary 'page' object
for (const openedPage of pages) {
if (openedPage !== page) {
console.log(`Closing extraneous page: ${openedPage.url()}`);
await openedPage.close();
}
}
// page.goto(...) next
```
```javascript theme={null}
const pages = await browser.pages();
const page = pages[0]; // Assume the first one is your primary page
await page.waitForTimeout(2000);
// Close all other pages except the primary one
for (const openedPage of pages) {
if (openedPage !== page) {
console.log(`Closing extraneous page: ${openedPage.url()}`);
await openedPage.close();
}
}
```
```javascript theme={null}
// FOR SELENIUM ONLY
const { closeWelcomePage } = require("@requestly/rq-automation");
await closeWelcomePage(driver);
```
Once the browser is launched with Requestly Interceptor, hit the following URLs to programmatically apply rules:
#### Add Request Header
To add multiple headers, simply append them using the `&` symbol like this:\
`?header1=value1&header2=value2&header3=value3`
```bash theme={null}
https://app.requestly.io/automation/add-request-header?=
```
#### Add Response Header
```bash theme={null}
https://app.requestly.io/automation/add-response-header?=
```
#### Remove Request Headers
To remove multiple headers, simply append them using the `&` symbol like this:\
`?header1&header2&header3`
```bash theme={null}
https://app.requestly.io/automation/remove-request-header?
```
#### Remove Response Headers
```bash theme={null}
https://app.requestly.io/automation/remove-response-header?
```
```javascript theme={null}
const {
addRequestHeaderUrl,
addRequestHeadersUrl,
removeRequestHeaderUrl,
removeRequestHeadersUrl,
addResponseHeaderUrl,
addResponseHeadersUrl,
removeResponseHeaderUrl,
removeResponseHeadersUrl,
} = require("@requestly/rq-automation");
// Add a single request header
await driver.get(addRequestHeaderUrl("X-Custom-Header", "MyValue"));
// Add multiple request headers
await driver.get(
addRequestHeadersUrl({
Authorization: "Bearer token123",
"X-Another-Header": "AnotherValue",
})
);
// Remove a request header
await driver.get(removeRequestHeaderUrl("X-Another-Header"));
// Remove multiple request headers
await driver.get(
removeRequestHeadersUrl(["Authorization", "X-Custom-Header"])
);
// Add a response header
await driver.get(addResponseHeaderUrl("Access-Control-Allow-Origin", "*"));
// Add multiple response headers
await driver.get(
addResponseHeadersUrl({
"X-Response-Header": "ResponseValue",
"X-Another-Response-Header": "AnotherResponseValue",
})
);
// Remove a response header
await driver.get(removeResponseHeaderUrl("X-Another-Response-Header"));
// Remove multiple response headers
await driver.get(
removeResponseHeadersUrl(["X-Response-Header", "X-Another-Response-Header"])
);
```
To verify if the headers are successfully modified, open [https://testheaders.com](https://testheaders.com) in the automated browser and inspect the headers shown.
*You may need to trigger a button click to reveal headers on some pages.*
### Complete Working Example in Selenium ( Javascript )
Here’s a working example using **Selenium**, but this logic can be adapted easily to **Playwright**, **Puppeteer**, or others.
```javascript theme={null}
const { Builder, By, until } = require("selenium-webdriver");
const chrome = require("selenium-webdriver/chrome");
const path = require("path");
(async () => {
const options = new chrome.Options();
options.setChromeBinaryPath("/Path/to/chrome-for-testing");
options.addExtensions(path.resolve(__dirname, "requestly.crx"));
const driver = await new Builder()
.forBrowser("chrome")
.setChromeOptions(options)
.build();
// give Chrome a moment for any stray tabs
await driver.sleep(500);
// close any “welcome” tab if still present
const handles = await driver.getAllWindowHandles();
const mainHandle = handles[0];
for (const handle of handles.slice(1)) {
await driver.switchTo().window(handle);
await driver.close();
}
await driver.switchTo().window(mainHandle)
try {
await driver.get("https://app.requestly.io/automation/add-request-header?x-testing=selenium");
await driver.wait(
until.elementTextContains(
driver.findElement(By.tagName("body")),
"Success"
),
1000
);
await driver.get("https://testheaders.com");
await driver.findElement(By.css("button")).click();
await driver.wait(
until.elementTextContains(
driver.findElement(By.tagName("body")),
"x-testing"
),
5000
);
console.log("Header added and verified!");
} catch (err) {
console.error("Error during automation:", err);
} finally {
await driver.quit();
}
})();
```
```javascript theme={null}
const {
addRequestHeaderUrl,
addRequestHeadersUrl,
removeRequestHeaderUrl,
removeRequestHeadersUrl,
addResponseHeaderUrl,
addResponseHeadersUrl,
removeResponseHeaderUrl,
removeResponseHeadersUrl,
importRules,
closeWelcomePage,
} = require("@requestly/rq-automation");
const { Builder } = require("selenium-webdriver");
const chrome = require("selenium-webdriver/chrome");
const { getExtension } = require("@requestly/rq-automation");
async function setupDriver() {
const options = new chrome.Options();
// Load Requestly Interceptor extension
const extensionPath = getExtension("unpacked");
options.addArguments(`--load-extension=${extensionPath}`);
options.addArguments(`--disable-extensions-except=${extensionPath}`);
const driver = await new Builder()
.forBrowser("chrome")
.setChromeOptions(options)
.build();
return driver;
}
async function seleniumExample() {
const driver = await setupDriver();
await closeWelcomePage(driver);
// Add a single request header
await driver.get(addRequestHeaderUrl("X-Custom-Header", "MyValue"));
// Add multiple request headers
await driver.get(
addRequestHeadersUrl({
Authorization: "Bearer token123",
"X-Another-Header": "AnotherValue",
})
);
// Remove a request header
await driver.get(removeRequestHeaderUrl("X-Another-Header"));
// Remove multiple request headers
await driver.get(
removeRequestHeadersUrl(["Authorization", "X-Custom-Header"])
);
// Add a response header
await driver.get(addResponseHeaderUrl("Access-Control-Allow-Origin", "*"));
// Add multiple response headers
await driver.get(
addResponseHeadersUrl({
"X-Response-Header": "ResponseValue",
"X-Another-Response-Header": "AnotherResponseValue",
})
);
// Remove a response header
await driver.get(removeResponseHeaderUrl("X-Another-Response-Header"));
// Remove multiple response headers
await driver.get(
removeResponseHeadersUrl(["X-Response-Header", "X-Another-Response-Header"])
);
// Import a shared list of rules
await driver.get(importRules("YOUR_API_KEY"));
// Your test code here
await driver.get("https://example.com");
await driver.quit();
}
seleniumExample();
```
# Modifying response asynchronously
Source: https://interceptor-docs.requestly.com/guides/modifying-response-asynchronously
Before going into Async Modifications, lets learn about Requestly Interceptor Response Rule a little bit.
[Requestly Interceptor Response Rule](/http-rules/rule-types/modify-response-body) comes in handy when you have to modify the response of a Request. You can either modify the response using `Static Data` or `Programmatically` write a script to modify the response.
## **Programmatic Response Rule**
Modifying Response body using Programmatic mode is really powerful. You can modify the response body programmatically based on incoming request's headers, status code, request method etc.
For example, this rule changes the response body to `{"foo": "bar"}` when request method is `GET` and return original response for rest of the methods.
```bash theme={null}
function modifyResponse(args) {
const {method, url, response, responseType, requestHeaders, requestData, responseJSON} = args;
// Change response below depending upon request attributes received in args
if(method === "GET") {
return {"foo": "bar"}
}
return response;
}
```
## **Async Modifications**
Async modifications lets you perform some long running tasks before returning the response. You can learn about async await from [here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function). This can be helpful in the following scenarios:
## Usecases
* Changing response based on response from some other URL.
- Respond to the request with the response from another website.
* Adding delays in Response (This is also possible using [Requestly Interceptor Delay Rule](/http-rules/rule-types/delay-network-requests))
### **Example 1**
In this example, we'll try to hit an external URL to fetch the auth\_token and then add the token in the original response.
> Rule: [https://app.requestly.io/rules#sharedList/1677765397812-Async-Modification-Response-Rule](https://app.requestly.io/rules#sharedList/1677765397812-Async-Modification-Response-Rule)
Original Response
Updated Response with token
1. Fetching Token from URL `https://demo_requestly.requestly.dev/auth_token`.
2) Adding token in Response.
### Example 2
This example changes the response of a non-existent domain ([https://non-existent-url.com](https://non-existent-url.com/)) by fetching the response from another url ([https://demo\_requestly.requestly.dev/users/1](https://demo_requestly.requestly.dev/users/1))
> Rule: [https://app.requestly.io/rules#sharedList/1677766334864-Async-Modification-Changing-response-of-non-existent-domain-programmatically](https://app.requestly.io/rules#sharedList/1677766334864-Async-Modification-Changing-response-of-non-existent-domain-programmatically)
Original Response
Updated Response
# Claim Your Requestly Interceptor GitHub Student Pack Benefit
Source: https://interceptor-docs.requestly.com/guides/other/claim-your-requestly-github-student-pack-benefit
Requestly Interceptor is an open-source tool for intercepting, modifying, and mocking HTTP requests and responses. We’re excited to offer Requestly Interceptor Professional (a \$270/year plan) free for one year to students who have been verified through the GitHub Student Developer Pack. Follow the steps below to verify your student status, access the Requestly Interceptor offer, and start using Requestly Interceptor Professional at no cost.
## Verify Your GitHub Student Status
To redeem the Requestly Interceptor offer, you first need an approved GitHub Education account. If you haven’t already, **apply for the GitHub Student Developer Pack** by submitting proof of enrollment (such as a school email, student ID, or transcript).
GitHub’s documentation guides you through this process: navigate to your Education benefits in GitHub settings, click “Start an application,” and submit the form. Once GitHub reviews and verifies your student status, your account will be eligible for Student Pack benefits.
## Access the Requestly Interceptor Student Offer
After your GitHub account is verified, you can now **claim your Requestly Interceptor benefit**:
* **Go to Requestly Interceptor’s GitHub Education page:** Visit [**requestly.com/github-education**](https://requestly.com/github-education) or find Requestly Interceptor on the [GitHub Student Developer Pack](https://education.github.com/pack#:~:text=About%20Requestly,and%20manage%20APIs).
* Click **Sign in with GitHub:** You’ll be redirected to the Requestly Interceptor app. Here, click **Connect with GitHub.**
* **Login or Sign Up on Requestly Interceptor:**
* If you already have a Requestly Interceptor account (using the same GitHub email), simply log in and proceed.
* If you don’t have a Requestly Interceptor account, click **Sign Up** to create one. Once your account is created, return and click **Connect with GitHub** again.
* **Benefit Activated:** Once connected, your GitHub Student verification will apply automatically, and your Requestly Interceptor account will be upgraded with the Student Pack access
## Enjoy Requestly Interceptor Professional
Now that you’ve redeemed the offer, you can use Requestly Interceptor Professional just like any paid user, with features like advanced API interception, mocking, and testing. No further action is needed. Your free **one-year access** begins immediately upon signing in.
* **Verify your plan:** In the Requestly Interceptor app or dashboard, you should see that your plan is upgraded to Professional.
* **Use Requestly Interceptor:** Create rules to intercept or modify HTTP requests, mock APIs, and debug your apps. Consult the Requestly Interceptor Docs for tips and tutorials.
After one year, if you’re still a student, you’ll have the option to switch to the free tier or subscribe at the regular price
*\*\* This promotional credit can only be redeemed once per student.*
## Need Help?
* **GitHub Education support:** For questions about your GitHub Education account or Pack benefits, see the GitHub Education site or [GitHub’s help docs](https://github.com/education).
* **Requestly Interceptor support:** For issues with Requestly Interceptor (redeeming the offer, account access, etc.), contact Requestly Interceptor support at [support@requestly.io](mailto:support@requestly.io) or visit our [Help Center](https://requestly.com/support/).
# Record and Mock Flaky APIs in bulk
Source: https://interceptor-docs.requestly.com/guides/record-and-mock-flaky-apis-in-bulk
This guide provides detailed instructions on how to use Requestly Interceptor for mocking API requests to ensure reliable development workflows.
Mocking will be accomplished using the [Modify Response rule](/http-rules/rule-types/modify-response-body), which allows overriding the response of an API.
This feature is available only on the [Desktop App](https://requestly.com/desktop/).
### **Recording traffic**
1. **Connect an App**: Launch a new app or connect an existing app with Requestly Interceptor to start intercepting network traffic. Learn more [here](/interceptor/overview).
2) **Capture Network Traffic**: Perform actions in your app to generate network traffic. Monitor and review this traffic within Requestly Interceptor.
3. **Save and Navigate to the Captured Session**: Once all desired requests are captured, save this data as a session and proceed to the session details.
### **Creating Mocks**
1. **Create Mocks from the Session**: Click on 'Create Mocks from this Session' button. Then, select the type of APIs you want to mock.
* For REST APIs: Filter and select the requests you wish to mock.
* For GraphQL APIs: Apply a Payload Filter to find specific requests containing the desired key. Then, filter and select the requests you wish to mock.
2) **Specify Matching Conditions to Create Rules**: Define the rules for mocking by choosing matching conditions such as matching the entire URL, only the path, or both path and query parameters. Review the created rules in the rules index.
### **Testing the Mocks**
1. **Navigate to the Traffic Interceptor**: Use the sidebar to access the traffic interceptor section and reconnect your app.
2) **Retrace your flow to Test Mocks**: Retrace the actions in your app to test the behaviour of the mocked requests. Look for highlighted requests in the logs, which indicate modifications by the mocking rules.
3) **Review and Edit Rules**: Click on the applied rules icon on any modified request to view or edit the rule definitions directly.
This process ensures a consistent development environment, as the APIs always return the expected responses and thus you gain independence from the current status of the API/service.
The current system can't handle the large volume of rules created in bulk, which in certain cases prevents users from creating multiple mocks when many mocks already exist. This is a technical debt, and we are working on a fix for upcoming releases. If you encounter this issue, you can use this workaround to continue testing.
We recommend backing up your rules in advance. To do this, select all your rules and click on the "Share Rules" button. Then, choose the option to download the rules to obtain a local copy.
A simpler way could be to delete the rules that you no longer need. If you are still not able to create mocks, please turn off syncing in the [Global Settings](https://app.requestly.io/settings/global-settings).
Disabling syncing will allow you to create as many rules as you need. However, be aware that your rules will be local and not synced across your devices.
# Requestly Interceptor Integration with BrowserStack App Live
Source: https://interceptor-docs.requestly.com/guides/requestly-integration-browserstack-app-live
Learn how to use Requestly Interceptor with BrowserStack App Live to inspect and modify network requests by configuring BrowserStack Local and system proxy settings.
## Prerequisite
1. Download [Requestly Interceptor Desktop app](https://requestly.com/downloads/desktop/)
2. You will also need your browser stack access key.
1. Go to your browser stack account’s settings page - [https://www.browserstack.com/accounts/settings](https://www.browserstack.com/accounts/settings)
2. Under the product section you should see an `Access Key` under the `Local Testing` section
Next you will need to setup the BrowserStackLocal App
## Setup BrowserStackLocal
1. Download the [BrowserStackLocal App](https://www.browserstack.com/docs/local-testing/releases-and-downloads)
2. Start the [Local App](https://www.browserstack.com/docs/app-live/local-testing#enable-local-testing)
3. Open the Local dashboard at [http://localhost:45454/](http://localhost:45454/)
4. Under **Tunnel Settings,** set the ip and port as shown in the Requestly Interceptor dashboard
5. Enable the `Force Local` option.
6. Click `Show More` and enable `Force Proxy` and `MITM Proxy` options.
7. Scroll to the top and click `Update Command` to apply the settings.
1. Download [BrowserStackLocal Binary](https://www.browserstack.com/docs/local-testing/releases-and-downloads).
2. Open command-prompt/terminal and run the following command.
```powershell theme={null}
./ --key --local-proxy-host --local-proxy-port --force-proxy --force-local
```
3. ensure to replace the `access key` , `proxy_ip` and `proxy_port`
## Start an App Live session
1. Log in to the [App Live](https://app-live.browserstack.com/?_gl=1*xznwek*_gcl_au*NjIyODA0NTY2LjE3Mjg5ODY1Mzk.) dashboard.
2. Verify that **Force Local** is **On**.
3. In **Devtools**, click the **Network** tab, and select the **Enable for all traffic** option. Click **Apply**.
You should now be able to see all the requests from your app session running inside browserstack. You can also modify these requests using [Requestly Interceptor Rules](/http-rules/overview) and see them take effect inside the App Live session.
# Advanced Usage
Source: https://interceptor-docs.requestly.com/http-rules/advanced-usage
Learn about advance features of Requestly Interceptor, designed to help you optimize your workflows and enhance productivity. Below, you'll find an overview of key advanced features, each linking to a detailed page for further exploration. Click on a card to learn more.
**Organize your rules efficiently.** Group related rules together for better organization and easier management.
**Access your frequently used rules quickly.** Pin your most important rules to the top for faster access.
**Modify and test GraphQL queries.** Take full control of GraphQL requests and responses with ease.
**Filter rules based on request source.** Apply rules conditionally depending on the source of the request.
**Validate rules instantly.** Use the "Test This Rule" feature to ensure your rules work as intended.
**Store and share data dynamically across rules.** Use \$sharedState for conditional edits, data aggregation, and token handling.
**Toggle Requestly Interceptor on demand.** Easily pause or resume all rules to suit your workflow.
**Keep rule statuses consistent across devices.** Ensure your rules stay in sync, no matter where you use Requestly Interceptor.
**Create precise rule conditions.** Use advanced filters like regex and wildcards for granular control.
# Advance Filters
Source: https://interceptor-docs.requestly.com/http-rules/advanced-usage/advance-filters
Enhance your source conditions with additional filters. These can be accessed using the filters button next to the input field
### Supported Options
Filter options vary depending on the type of rule you're working with. Here's a breakdown of what's available:
**Common Filters (Available for Most Rules):**
* **Page Domain Name:** Limit targeting to requests originating from a specific domain. This is especially useful for distinguishing between network calls made from different websites, such as CDN calls shared across multiple domains.
* **Resource Type:** Specify the type of resource to limit matching to particular requests. For instance, path-level matching can apply to both CSS and JavaScript files, but advanced filters allow narrowing it down to only CSS or JavaScript as needed.
* **Request Method:** Filter based on the HTTP method (e.g., GET, POST, OPTIONS). For example, two requests can have the same path but behave differently based on the method used. An API call to a resource with the GET method retrieves the resource details, while a PATCH call updates the resource.
### Modify Request Body & Modify API Response
Only the **Request Method** filter is available for these rule types.\
Use it to precisely target requests based on how they're made.
### Insert Script Rule
**Resource Type**\
Specify where the script should be injected:
* **Main Document**: Insert into the main page
* **iFrame Document**: Inject into an embedded iframe
# GraphQL Support
Source: https://interceptor-docs.requestly.com/http-rules/advanced-usage/graphql-modify-request-response
Learn to modify GraphQL API requests and responses using Requestly Interceptor to debug and test GraphQL APIs.
***
Unlike REST APIs, GraphQL APIs provide a flexible approach to querying and mutating data through a single endpoint. They allow clients to specify exactly what data is needed, reducing over-fetching and under-fetching issues common with REST APIs. GraphQL APIs can be modified to customize requests and responses for testing and debugging. This guide provides detailed steps to achieve this using Requestly Interceptor.
## Modifying GraphQL Responses
In GraphQL, client interactions are typically managed through a single HTTP endpoint. The specific operation to execute is often indicated by the `operationName` field in the request payload.
**Example Request**
```bash theme={null}
POST
{
"operationName": "getUsers",
"query": `
query getUsers {
users {
id
email
}
}
`
}
```
To modify the response of a GraphQL API:
### Steps to Modify API Response
Navigate to the HTTP Rules section in the web or desktop app.
Click on "+ New Rule" and select **Modify API Response**.
Choose "GraphQL API" as the Resource Type.
In the **GraphQL Operation (Request Payload Filter)** section:
* Enter **Key** as `operationName`.
* Enter **Value** as the operation name you want to target (e.g., `getUsers`).
Define the new response you want to serve for the specified operation.
Click **Save** to store the rule and toggle it ON to apply the changes.
Validate the rule by sending a request matching your conditions and verifying the modified response.
For additional details, visit the Modify API Response Rule Page.
**Notes**
* The **Key** represents the JSON key in the request payload and supports nested paths. For example:
* If `operationName` is located at `data.operationName`, specify `data.operationName`.
* For array payloads, such as `[{"operationName": "value"}]`, use `0.operationName` as the key.
* If the request does not include `operationName`, select **Resource Type** as "REST API" and use **Dynamic (JavaScript) Mode** to filter and modify the response.
### Example Without `operationName`
In cases where the operation is specified within the `query` field:
```bash theme={null}
POST /graphql
{
"query": `
query getUsers {
users {
id
email
}
}
`
}
```
You can modify the response using a JavaScript snippet:
```jsx theme={null}
function modifyResponse(args) {
const { url, response, requestData, responseJSON } = args;
if (requestData.query?.includes("query getUsers")) {
console.log("Requestly Interceptor: Modifying response", { query: requestData.query });
return { ...responseJSON, custom: true };
}
return response;
}
```
***
## Modifying GraphQL Requests
If you need to alter the GraphQL query or its variables, use the **Modify Request Body** rule to change the request payload dynamically.
### Steps to Modify Request Body
Navigate to the HTTP Rules tab in the web or desktop app.
Click on "+ New Rule" and select **Modify Request Body**.
Choose "GraphQL API" as the Resource Type.
In the **GraphQL Operation (Request Payload Filter)** section:
* Enter **Key** as `operationName`.
* Enter **Value** as the operation name you want to target (e.g., `getUsers`).
Define the new Request you want to serve for the specified operation
Click **Save** to store the rule and toggle it ON to apply the changes
Validate the rule by sending a request matching your conditions and verifying the modified response.
For additional details, visit the Modify Request Rule Page.
# Grouping
Source: https://interceptor-docs.requestly.com/http-rules/advanced-usage/grouping
Learn how to organize and manage Requestly Interceptor rules efficiently by grouping them for easier management and toggle status.
***
Requestly Interceptor offers ten distinct types of rules that allow you to override default network request behaviors in a webpage. As the number of rules increases, managing them individually can become cumbersome. To address this, Requestly Interceptor provides the ability to organize these rules into logical groups, enabling you to enable or disable them as a set.
### Creating a New Group
To create a new group in Requestly Interceptor, follow these steps:
Navigate to the Requestly Interceptor Dashboard and open HTTP Rules.
Click the "New Group" button. You can add multiple rules under a single group name to keep them organized.
### Moving Existing Rules to a Group
If you already have existing rules that need to be grouped, you can do so by:
Choose the rules you wish to group together.
Click on the "Change Group" option, which will open the Group Modal.
In the Group Modal, select an existing group or create a new one to organize the rules.
### Enabling and Disabling Groups
Once your rules are grouped, you can enable or disable an entire group in one go. This is particularly useful when managing rules for different projects or environments.
### Ungrouping Rules
If you wish to remove a rule from a group, select the rule and ungroup it. This will return it to its standalone state, allowing you to manage it independently.
# Multiple Conditions in a Single Rule in Requestly Interceptor
Source: https://interceptor-docs.requestly.com/http-rules/advanced-usage/multiple-conditions-in-a-single-rule-in-requestly
Learn how to define and use multiple conditions in a single rule in Requestly Interceptor to optimise rule management.
Requestly Interceptor allows users to define **multiple conditions within a single rule**, making request modifications easier. Instead of creating separate rules for each scenario, you can configure a single rule to handle multiple actions, targeting multiple URLs at once in a single rule.
### How Multiple Conditions Work
Requestly Interceptor evaluates multiple conditions within a single rule independently. If a condition matches, the corresponding action is executed. This allows users to apply different modifications without needing separate rules for each case.
### Why to use Multiple Conditions in a Single Rule?
Using multiple conditions in a single rule makes your workspace cleaner and more efficient. Instead of creating a bunch of separate rules for small tweaks, you can group related changes together in one neat, easy-to-manage rule.
### Redirect Rule
The **Redirect Rule** in Requestly Interceptor allows users to define multiple conditions within a single rule, enabling different URLs to be redirected to different destinations. Instead of creating separate redirect rules for each URL, you can consolidate multiple redirections into one rule for better organization and efficiency.
**Key Points to Remember**
* Each condition is evaluated **independently**.
* If multiple conditions match the same request, the **first defined condition** in the rule takes precedence.
### Replace Rule
The **Replace Rule** in Requestly Interceptor allows users to define multiple conditions within a single rule to modify different parts of a URL dynamically. Instead of creating separate replace rules for different replacements, you can manage them all in one rule, ensuring efficient and flexible URL transformations.
**Key Points to Remember**
* Each condition is evaluated **independently**, meaning multiple replacements can be applied to the same request.
* If multiple conditions modify overlapping parts of the URL, they execute **in the order they are defined** in the rule.
### Query Param Rule
The **Query Param Rule** in Requestly Interceptor allows users to define multiple conditions within a single rule to modify query parameters in different URLs. Instead of manually appending, updating, or removing query parameters in multiple rules, you can consolidate all changes into one rule .
**Key Points to Remember**
* Each condition applies **independently** based on the matching URL pattern.
* **If a query parameter is added and then modified later**, the modified value will be the final one applied.
### Modify Headers Rule
The **Modify Headers Rule** in Requestly Interceptor allows users to define multiple conditions within a single rule to **add, modify, or remove HTTP headers** across different URLs. Instead of creating multiple rules for different header modifications, you can consolidate them into one rule, ensuring efficiency and better rule management.
**Key Points to Remember**
* Each condition applies **independently** to the matching URLs.
* **Header modifications follow the order they are listed.** If a header is **added first and then modified**, the modified value will be the final one applied.
### Modify User Agent
The **Modify User Agent Rule** in Requestly Interceptor allows users to define multiple conditions within a single rule to **modify the User-Agent header** for different URLs. This is particularly useful for testing how a website behaves across different browsers, devices, and platforms without needing to use actual devices or browser extensions.
**Key Points to Remember**
* Each condition applies **independently** to the matching URLs.
* If multiple conditions match the same URL, the **last matching condition will take precedence**.
* The modified **User-Agent is sent with all requests** to the specified URLs, affecting how servers respond.
### Cancel Request Rule
The **Cancel Request Rule** in Requestly Interceptor allows users to define multiple conditions within a single rule to **block specific requests** based on different URLs. This is useful for preventing unnecessary or harmful requests, improving performance, and ensuring a cleaner browsing or testing environment.
**Key Points to Remember**
* Each condition applies **independently** to the matching URLs.
* Once a request is **canceled**, no further processing occurs for that request.
* The rule applies to **both browser requests and API calls**, ensuring unwanted requests are blocked across different scenarios.
### Delay Network Request Rule
The **Delay Network Request Rule** in Requestly Interceptor allows users to define multiple conditions within a single rule to **artificially delay specific requests**. This is useful for testing how applications behave under slow network conditions or simulating real-world latency issues.
**Key Points to Remember**
* Each condition applies **independently** to the matching URLs.
* **Delays apply only to matched requests**, meaning unrelated requests remain unaffected.
* Requests are **paused before reaching the server**, simulating real-world latency.
### Insert Script Rule
Insert Script rule allows you to insert multiple scripts and styles on a single page all the scripts are executed serially, You define a **single condition**, specifying the URL where the scripts should be injected. Multiple JavaScript and CSS files can be added to that page. Scripts and styles execute **serially, in order**, ensuring dependencies are handled correctly.
**How It Works**
* You define a **single condition**, specifying the URL where the scripts should be injected.
* Multiple JavaScript and CSS files can be added to that page.
* Scripts and styles execute **serially, in order**, ensuring dependencies are handled correctly.
**Key Points to Remember**
* **Single Condition:** The rule applies to **one URL pattern** only.
* **Multiple Scripts and Styles:** You can inject multiple JavaScript and CSS files.
* **Serial Execution:** Scripts run **one after another**, following the specified order.
* **Ensuring Dependencies:** If one script depends on another, place it **later in the order**.
**Best Practices**
* **Load Dependencies First:** If a script relies on another (e.g., jQuery), inject it **before** dependent scripts.
* **Use Minified Versions:** For better performance, use minified .js and .css files.
* **Avoid Blocking UI:** Large scripts should be loaded asynchronously when possible.
* **Test in Requestly Interceptor:** Use the **Test Rule** feature to ensure scripts load in the right sequence.
# Pause/Resume Requestly Interceptor
Source: https://interceptor-docs.requestly.com/http-rules/advanced-usage/pauseresume-requestly
Learn how to temporarily pause and resume Requestly Interceptor rules to test your website’s original behavior without interference.
***
Requestly Interceptor provides an easy way to intercept and modify web requests, but there are instances when you might want to pause its functionality temporarily. This document outlines how to pause and resume Requestly Interceptor to test your website's original behavior without interference from active Requestly Interceptor rules.
## Pausing Requestly Interceptor
To temporarily stop Requestly Interceptor from intercepting and modifying web requests, follow these steps:
Locate and click the Requestly Interceptor icon in your browser’s toolbar to open the menu.
Find the toggle labeled "Requestly Interceptor running." Click it to deactivate Requestly Interceptor. The label will change to "Requestly Interceptor paused," indicating that Requestly Interceptor is now inactive and no rules are being applied.
## Resuming Requestly Interceptor
To re-enable Requestly Interceptor and allow its rules to intercept and modify requests again, follow these steps:
Locate and click the Requestly Interceptor icon in your browser’s toolbar to open the menu.
Click the Requestly Interceptor icon in your browser’s toolbar and find the toggle labeled "Requestly Interceptor paused." Click the toggle to activate Requestly Interceptor. The label will change to "Requestly Interceptor running," confirming activation.
Refresh your browser page to ensure that Requestly Interceptor’s rules are properly applied.
# Pinning Rules
Source: https://interceptor-docs.requestly.com/http-rules/advanced-usage/pinning-rules
Pin rules in Requestly Interceptor for quick access and easy toggling directly from the Chrome toolbar.
***
Pinning rules in Requestly Interceptor allows you to quickly access and manage your rules directly from the Chrome toolbar, streamlining your workflow without the need to open the Requestly Interceptor app. This feature is particularly useful for toggling rules on or off with ease.
## Benefits of Pinning Rules
1. **Quick Access:** Access frequently used rules directly from the toolbar.
2. **Simplified Management**: Toggle rules on or off with a single click.
3. **Improved Workflow**: Avoid the need to open the Requestly Interceptor app, streamlining your debugging or testing tasks.
## How to Pin a Rule
To pin a rule in Requestly Interceptor, follow these steps:
Navigate to the list of rules in your Requestly Interceptor dashboard.
On the left side of the rule, you will see a ‘Pin’ icon. Click on it to pin the rule to your toolbar. You can also pin a group.
Once pinned, the rule will be accessible from the Requestly Interceptor icon in your Chrome toolbar.
### Accessing Pinned Rules
To access and manage your pinned rules:
Click on the Requestly Interceptor icon located on the Chrome toolbar.
You will see a list of your pinned rules. From here, you can toggle each rule on or off with just one click.
# Rules Status Syncing
Source: https://interceptor-docs.requestly.com/http-rules/advanced-usage/rules-status-syncing
Learn how to manage rules status syncing in team workspaces to ensure consistent configurations or independent rule management.
***
Rules status syncing allows all members of a shared workspace to maintain consistent rule statuses. If one user enables a rule, the rule is automatically enabled across the workspace for all members. This feature is particularly beneficial for teams involving non-technical roles, such as sales or customer success, ensuring that the same configurations are applied universally.
In a standard development workflow, it is generally recommended to keep rules status syncing turned off to avoid unintended changes affecting all users.
### Enabling Rules Status Syncing
Rules status syncing can only be activated in team workspaces. To enable this setting, follow the steps below:
Switch to the desired workspace using the workspace switcher dropdown. From the dropdown, open the "Manage Workspace" link.
In the workspace management interface, switch to the "Workspace Settings" tab. This tab contains various configuration options specific to the workspace.
Locate the toggle option labeled **"Enable status syncing in team workspaces."** Use this toggle to enable or disable rules status syncing across workspace members as required.
Once this setting is enabled, any changes to rule statuses by one user will automatically reflect for all workspace members. Conversely, disabling this feature will allow individual users to manage rule statuses independently.
# Shared State
Source: https://interceptor-docs.requestly.com/http-rules/advanced-usage/shared-state
Discover how to use Shared State in Requestly Interceptor to manage data across Modify Request and Response rules with examples and best practices.
***
Shared State allows developers to store and retrieve data within and across Modify Request Body and Modify API Response rules. This functionality is facilitated by `$sharedState`, a JavaScript object where you can assign key-value pairs to enhance rule customisation.
Shared State was introduced in the Requestly Interceptor extension version `24.8.13` and Desktop App `1.7.1` . Make sure you are using the latest version.
## Use Cases for Shared State
1. **Conditional Request/Response Modification**: Use shared state to modify requests or responses dynamically based on conditions stored in prior requests. For example, you can conditionally fail requests based on request counts.
2. **Data Aggregation Across Requests**: Collect and aggregate data from multiple requests to use within a rule. For instance, you can store API responses and utilize them for further processing across different Requestly Interceptor rules.
3. **Token Management Across API Requests**: Manage shared values such as tokens or other critical data across various API interactions, streamlining complex workflows.
## How to Use Shared State
Start by creating a new "Modify Request" or "Modify Response" rule in Requestly Interceptor. You can access this feature in both the web app and desktop versions.
In the rule editor, select "Dynamic JavaScript Modification" to leverage `$sharedState`. This enables the use of JavaScript for programmatic customisation.
You can store and retrieve values using `$sharedState` within your JavaScript code.
```javascript theme={null}
function modifyResponse(args) {
const {
method, url, response,
responseType, requestHeaders,
requestData, responseJSON
} = args;
const [urlPath, queryParams] = url.split('?');
// Store Request URLs and their responses
const urlMap = $sharedState.urlMap || {};
urlMap[urlPath] = response;
$sharedState.urlMap = urlMap;
// Block all subsequent requests if a specific URL was accessed
if ($sharedState.urlMap &&
"https://mock.redq.io/api/products" in $sharedState.urlMap) {
console.log("Blocked: "+urlPath);
return null;
}
return response;
}
```
## Best Practices
* **Namespace Your Keys**: Use structured keys (e.g., `"moduleX.keyY"`) to avoid overwriting shared data.
* **Clean Up When Done**: Remove unnecessary data to prevent memory bloat.
* **Test Thoroughly**: Ensure that shared state logic doesn’t introduce unintended side effects.
## Frequently Asked Questions
You can set and retrieve data in the shared state as shown below:
**Set a Value:**
```jsx theme={null}
$sharedState.myVariable = "some value";
```
**Retrieve a Value:**
```jsx theme={null}
let myValue = $sharedState.myVariable;
```
You can store any data type that can be serialized into JSON, such as strings, numbers, booleans, objects, and arrays.
`$sharedState` has different runtime contexts in the Requestly Interceptor Desktop App and the Requestly Interceptor browser extension.
* **Desktop App**: Data persists until the app is closed.
* **Browser Extension**: Data persists as long as the browser tab is open.
Use `$sharedState` to count requests and dynamically control behavior:
```jsx theme={null}
function modifyResponse(args) {
const {
method, url, response,
responseType, requestHeaders,
requestData, responseJSON
} = args;
let count=$sharedState.count ?? 0;
++count;
$sharedState.count=count;
// Succeed if it is not the first request
if($sharedState.count>3){
return response;
} else {
return null;
}
}
```
# Source Conditions
Source: https://interceptor-docs.requestly.com/http-rules/advanced-usage/source-conditions
Define source conditions and advanced filters for precise network request rules, including regex and wildcard testing.
***
Source conditions allow you to specify criteria for matching network requests. These criteria define where the rules should be applied, such as specific URLs, hosts, or paths.
Let's explore the elements of source conditions from left to right:
Select whether the matching should be performed on the host or the full URL.
Choose from four operators to define how the matching should be performed:
* **Equals:** Matches exactly the specified value.
* **Contains:** Matches if the value includes the specified substring.
* **Regex:** Enables pattern matching using regular expressions.
* **Wildcard:** Allows flexible pattern matching using wildcard characters.
The value of this field varies based on the operator selected. For **Equals**, enter the exact string to match, such as the full URL if you select the URL in the source. For **Contains**, provide a substring for broad matching across all URLs containing this string. For **Regex**, enter a regex pattern to match. For **Wildcard**, use a wildcard pattern to specify the matching criteria.
Enhance your source conditions with additional filters. These can be accessed using the filters button next to the input field:
1. **Page Domain Name**
* Targets requests based on the domain of the page making the request.
* Useful when the same request (e.g., a CDN file) is made from multiple websites
2. **Resource Type**
* Filter by the type of resource being requested.
* Common types include:
* `script`
* `stylesheet`
* `image`
* `xhr` (XMLHttpRequest or fetch)
* `document`, etc.
3. **Request Method**
* Filters requests based on the HTTP method (e.g., `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `OPTIONS`).
### Test URL Condition
The test URL condition feature is only applicable when using regex or wildcard operators. A button labeled **Test Regex** or **Test Wildcard** appears when you select these options. This feature helps you validate whether the rule source URL condition you have set up works for the request URL you want it to work with, improving the rule creation and editing experience.
To test a URL condition:
Start by opening any rule editor in the interface where you can define and edit source URL conditions.
Input the source URL condition using either the **Regex** or **Wildcard** operator, depending on your requirements.
Click on the **Test Regex** or **Test Wildcard** button (depending on the selected operator). This will open a test URL popup modal for validation.
This popup modal includes the following components:
* **Source Condition:** Displays the source condition defined in the rule editor. It is editable, allowing adjustments as needed.
* **URL Field:** Enter the complete URL you want the rule to be applied to.
* **Result:** Displays whether the rule will apply to the entered URL.
### Testing URL with Regex Condition
To test a URL with a regex pattern in the source URL condition, enter the complete URL in the URL field. The result will indicate whether the rule applies to the URL based on the regex pattern.
**Examples:**
| **Source Condition** | **Match with URL** | **Is Matched** |
| ----------------------------- | --------------------------------- | -------------- |
| `/^https://.*github.*/` | `https://subdomain.github.io/` | Yes |
| `/^https://blog\\..*\\.com$/` | `https://blog.example.com/` | Yes |
| `/^((?!example).)*$/` | `https://www.examplewebsite.com/` | No |
Ensure the regex pattern in the source condition is valid and enclosed with slashes (`/`).
**Examples**:
* `/^https://.*github.*/` ✅ Valid regex
* `/^https://.*github.*` ❌ Invalid regex
### Testing URL with Wildcard Condition
To test a URL with a wildcard pattern in the source URL condition, enter the complete URL in the URL field. The result will indicate whether the rule applies to the URL based on the wildcard pattern.
**Examples:**
| **Source Condition** | **Match with URL** | **Is Matched** |
| ----------------------- | ------------------------------------------------ | -------------- |
| `://*.yahoo.com` | `http://cricket.yahoo.com` | Yes |
| `*google.com*?param=*` | `https://www.google.com/page?param=value` | Yes |
| `*example.com*?param=*` | `https://www.examplewebsite.com/page?param=test` | No |
**Using Variables in Wildcard Patterns**
When you use the wildcard (`*`) operator, each `*` acts as a capturing group. The matched values are automatically stored in corresponding variables like `$1`, `$2`, and so on. These variables can then be used in the **destination configuration** (e.g., redirect URL, response modification, etc.) to dynamically refer to parts of the matched URL.
**Example:**
* **Wildcard Pattern**: `https://example.com/product/*/details/*`
* **Matched URL**: `https://example.com/product/123/details/shoes`
* **Captured Variables**:
* `$1 = 123`
* `$2 = shoes`
You can then use `$1` and `$2` in your rule actions, such as:
* **Redirect to**: `https://newstore.com/items/$1/info/$2`
* Result: `https://newstore.com/items/123/info/shoes`
This allows for powerful and dynamic rule creation using flexible wildcard patterns and extracted values.
# Test This Rule
Source: https://interceptor-docs.requestly.com/http-rules/advanced-usage/test-rules
Validate and debug HTTP rules in real-time using Requestly Interceptor's "Test This Rule" feature with session recording and detailed test reports.
***
The **Test This Rule** feature in the HTTP Rules section allows users to validate their rule configurations by applying them to a specific webpage or endpoint in real-time. This feature is especially useful for debugging, ensuring rules behave as expected before deploying them broadly.
## Why Use the Test This Rule Feature?
1. **Real-Time Feedback**: Instantly see how your rule affects the target webpage or API endpoint.
2. **Debugging and Optimisation**: Identify and resolve issues in your configurations before wider application.
## How to Use the Test This Rule Feature
Before using the **Test This Rule** feature, ensure that you have a configured rule ready. This can be any rule created under the HTTP Rules section, such as modifying requests, delaying network requests, or redirecting URLs. Save and activate the rule.
Tip: After saving the rule, the test panel opens automatically.
Open the test rule panel using the `Test` button located next to the "Add to Group" dropdown. Here, you’ll find an input field to enter the URL of the page or endpoint where you want to apply the rule.
Enter the URL of the webpage where you expect to apply your rule, and click the **Test Rule** button. Additionally, you can check the ***Save the test session with video, console & network logs*** checkbox if you want to capture session details during the test for deeper analysis.
After clicking the **Test Rule** button, the specified URL will open in a new tab or within the test environment. A widget will appear on the page, displaying the status of the applied rules. The widget allows you to:
* View details about the active rule.
* Confirm whether the rule has been applied as expected.
* Make adjustments if needed.
When you’re done with testing, click on the **View Results** button to generate a detailed test report in the rule editor. This report provides insights into how the rule performed and whether any adjustments are necessary.
## Advanced Usage: View Test Session
To gain more details about the test report, you can view the network and console logs of the testing session by clicking on the **Watch Session** button. Requestly Interceptor maintains reports for the last three tests you’ve run for each rule. Learn [more about the sessions here](/sessions/record-bug-reports).
## Key Considerations
* **Browser Limitations**: Modified request bodies or headers may not be visible in browser developer tools but are applied to the actual network request.
* **URL Compatibility**: Ensure the entered URL matches the source condition specified in the rule for accurate testing.
* **Performance Constraints**: For some rules, such as delaying network requests, ensure delays are within allowable thresholds to avoid performance bottlenecks.
# Validate Rules Execution
Source: https://interceptor-docs.requestly.com/http-rules/advanced-usage/validate-rules-execution
Learn how to verify if a Requestly Interceptor rule is executed successfully.
***
The way Requestly Interceptor shows rule executions varies between the browser extension and desktop app, tailored to their respective environments:
Once you have enabled a Requestly Interceptor rule to modify some part of a network request or the page, the next thing you would like to do is confirm if the rule executed successfully.
Here are 4 ways to know if a rule is executed on a page.
## 1. Extension icon turns green
If any of the rules executes on the current page, the Requestly Interceptor icon in the extension toolbar (next to the address bar) will turn from a normal icon to a green icon.
## 2. Status Notification Widget
A small widget appears in the **Top-right corner** of the page for **5 seconds** after the page loads or a rule is triggered.
***
### Disable the Widget
Click the **eye icon** on the widget when it appears. This will take you directly to **Global Settings**.
Find the option **"Show widget when rule is applied"** and toggle it off to disable the widget popup.
Customise when the widget appears under **Show widget on**:
* **All Rules**: Widget appears if **any rule** executes.
* **Specific Rules**: The widget appears **only for the rules you select**.
***
## 3. Executed Rules Tab in Popup
Click on the **Requestly Interceptor Icon** in the browser toolbar to open the extension.
Navigate to the **Executed Rules** tab to see the list of rules that ran on the current page.
***
## 4. Requestly Interceptor DevTools Tab
Right-click on the page and select **Inspect** or press **Ctrl+Shift+i** to open the DevTools.
Go to the **Requestly Interceptor tab** within DevTools.
Reload the page and navigate to the **Rule Executions** section to see the list of rules that ran on the current page.
The **rules table** visually highlights which rules were applied by turning the corresponding request rows **green**.
# Overview
Source: https://interceptor-docs.requestly.com/http-rules/overview
Learn when to use HTTP Rules, how to create your first rule, and which traffic modification workflows to explore next.
HTTP Rules are the fastest way to change traffic without changing your app. Use them to modify headers, rewrite request or response bodies, redirect calls, inject scripts, delay traffic, or map requests to local and remote resources.
## When To Use HTTP Rules
Use HTTP Rules when you want to:
* modify headers, query params, bodies, or user agents
* redirect requests between environments
* simulate errors, delays, and edge cases
* inject scripts or override resources during frontend testing
* create repeatable traffic changes for demos, debugging, and QA
If your goal is to inspect live traffic first, use [HTTP Interceptor](/interceptor/overview). If you need hosted mock endpoints, use [File Server](/mock-server/overview).
## Start With These Rule Types
Add, remove, or overwrite headers for debugging and API testing.
Switch requests between environments or alternate resources instantly.
Simulate backend changes, mock responses, and reproduce edge cases.
Reproduce slow networks and performance-related issues.
## First Success Path
Start with a single change such as [Modify Headers](/http-rules/rule-types/modify-headers) or [Redirect Rule](/http-rules/rule-types/redirect-rule).
Use URL and source conditions to target only the traffic you want to change.
Use [Test This Rule](/http-rules/advanced-usage/test-rules), app behavior, or your API workflow to confirm the traffic changed as expected.
## Explore By Workflow
Browse the full catalog of traffic modification capabilities.
Learn grouping, source conditions, testing, shared state, and filters.
Share, sync, and distribute rules with your team or workspace.
Migrate rule configurations from other tools and extensions.
## Related Capabilities
Use HTTP Interceptor when you need to see requests and responses before deciding what to modify.
Use File Server when you need reusable mock endpoints instead of in-place traffic overrides.
# HTTP Rules
Source: https://interceptor-docs.requestly.com/http-rules/rule-types
Learn about Requestly Interceptor's rule types like Redirect, Modify Headers, and Insert Script to customize and control your web requests effectively.
***
HTTP Rules in Requestly Interceptor enable you to efficiently control web traffic. With these rules, you can modify requests and responses, redirect or block network calls, insert custom scripts, and manage headers. These powerful tools help you customise and optimise your browsing experience for testing, debugging, or development purposes.
### Types of Rules
Adjust outgoing API request payloads to meet testing and development requirements. Add static or dynamic data to refine request structures.
Simulate API responses to test scenarios and edge cases. Use static data or dynamic transformations to validate application behavior
Add, remove, or modify HTTP headers for debugging and control
Block specific network calls or simulate failure scenarios
Add, remove, or modify query parameters to refine API requests.
Test different browser and device environments by customizing User-Agent headers.
Redirect requests to different URLs to switch environments or resources during development.
Modify URLs or paths by replacing specific substrings.
Inject JavaScript or CSS into web pages for advanced customization.
Simulate real-world network latencies by introducing delays.
Serve files from your local environment to test offline changes.
Redirect requests to different servers or environments for advanced testing.
# Cancel Request Rule
Source: https://interceptor-docs.requestly.com/http-rules/rule-types/cancel-rule
Learn how to block network requests using Cancel Request Rule. Explore key use cases like blocking distracting websites and testing error scenarios.
***
Cancel Request Rule is a feature used to block network requests, allowing users to avoid distractions or test specific error scenarios effectively. This guide explains how to configure and utilize the Cancel Request Rule in your workflow.
## Why Use Cancel Request Rule?
* **Blocking Distracting Websites:** Leverage the Cancel Rule to block access to websites such as YouTube, Twitter, or Facebook to stay focused. Set the source condition to match the URLs of these websites and enable the rule.
* **Testing Error Scenarios:** Simulate real-world application behaviors when resources are unavailable. For example, block a specific non-critical API request and observe how your application handles the missing resource.
## How to Configure Cancel Rule
Navigate to the HTTP Rules section in your application and click on the `+ New Rule` button. From the available options, select `Cancel Rule` to begin configuration.
Provide a **descriptive name** and an optional **description** for your Cancel Rule. This helps keep your rules organized and ensures clarity when managing multiple rules.
Define where the rule should be applied by specifying criteria such as **URL**, **Host**, or **Path**. You can choose from options like **Regex**, **Contains**, **Wildcard**, or **Equals**, or use **Advance Filters** for more precise conditions.
For more details on source conditions, [**read this guide**](/http-rules/advanced-usage/advance-targeting) **.**
Let’s try to block product listing API call on `https://www.requestly-playground.com/`
Once you have configured the conditions and filters, save the rule and toggle it on to activate. This ensures that the rule applies immediately to the specified requests.
To ensure the rule is working correctly, click the `Test` button and enter the URL of the page where the matching URL is called. This will open the webpage in a new tab, with a widget showing the status of applied rules.
There are multiple ways to validate if a rule is applied or not, learn more about how to **validate rule execution****.**
On loading the `https://www.requestly-playground.com/` website, it shows network error. A small widget on the page confirms that the Rule is applied. You can click on **View Results** button to view the result details.
# Delay Network Requests
Source: https://interceptor-docs.requestly.com/http-rules/rule-types/delay-network-requests
Learn how to configure HTTP rules to simulate network latency for testing slow connections
***
The **Delay Network Request** rule in Requestly Interceptor enables you to simulate network latency on HTTP requests for testing and debugging purposes. By adding delays, you can observe how your application behaves under slow network conditions.
## Why Use the Delay Network Requests?
* **Test Slow Network Scenarios:** Understand how your application handles slow connections, especially for users in remote areas.
* **Test API Latency:** Evaluate how your app behaves when one or more APIs respond slowly, ensuring appropriate error handling and fallback mechanisms.
* **Identify Race Conditions:** Check if any race conditions exist when resource X gets loaded before or after resource Y.
* **UI/UX Testing:** Verify if the user interface provides appropriate feedback (like loaders or error messages) during delays.
## How to Configure the Rule
Navigate to the HTTP Rules tab in the web or desktop app. Click on `+ New Rule` and select `Delay Network Requests` from the options.
Provide a **descriptive name** for the rule to keep your setup organized. Optionally, add a **brief description** explaining its purpose for easier identification later.
Define where the rule should be applied by specifying criteria such as **URL**, **Host**, or **Path**. You can choose from options like **Regex**, **Contains**, **Wildcard**, or **Equals**, or use **Advance Filters** for more precise conditions.
For more details on source conditions, [**read this guide**.](/http-rules/advanced-usage/advance-targeting)
To apply a rule to an API fetching product data on [our playground website](https://www.requestly-playground.com/), use the following configuration:
* **Condition Type:** URL
* **Operator:** Contains
* **Value:** `rest.requestly-playground.com/api/products`
This example targets the product data API of our playground website, [`https://www.requestly-playground.com/`](https://www.requestly-playground.com/)**.**
You can also import this rule and apply it directly by using this [**shared list**](https://app.requestly.io/rules/shared-lists/viewer/ba070616357f468593a2b16131e7ccd0-Delay-API-Response).
Specify the delay duration in milliseconds. For example, enter `4000` to introduce a 4-second delay.
**Delay Capping**, In the browser extension, delays are capped to prevent performance issues. The maximum delay is **5000 ms** for XHR/Fetch requests and **10000 ms** for other resources (JS, CSS, images, etc.). The Desktop App has no such restrictions.
Once you are satisfied with your configuration, click **Save** to store the rule. After saving, make sure to toggle the rule **ON** to activate it. This will apply the rule and ensure it works as expected.
To ensure the rule is working correctly, click the **Test** button and enter the URL of the page where you want to apply this rule.
There are multiple ways to validate if a rule is applied or not, learn more about how to **validate rule execution****.**
This will open the webpage in a new tab, with a widget showing the status of applier rules.
Here, You can see the requests are delayed, as the `Queued At`/`Started At` time in the Network tab goes up by 4 seconds (4000 ms).
# Insert Scripts
Source: https://interceptor-docs.requestly.com/http-rules/rule-types/insert-scripts
Learn how to use Requestly Interceptor's Insert Script Rule to inject JavaScript or CSS into web pages without changing the original code
***
The **Insert Scripts** Rule allows you to inject JavaScript/CSS into web pages before/after they load. This means you can modify the DOM, change styles, or even add new functionality without altering the source code directly. It’s important for testing hypotheses or debugging during development and quality assurance processes.
To see how the Insert Script Rule can be configured and applied in different scenarios, watch the video below, where we demonstrate its usage and potential
## Why Use the Insert Script Rule?
* Inject popular libraries or hosted scripts or execute custom code snippets on or after page load using a simple rule builder.\
[Learn more →](https://requestly.com/blog/how-to-inject-a-script-before-page-load-on-a-website/)
* Test & demonstrate SaaS applications like website widgets and monitoring scripts on target websites.\
Learn more →
## **How to Configure the Rule**
Navigate to the `HTTP Rules` tab in the web or desktop app. Click on `+ New Rule` and select `Insert Script` from the options.
Provide a **descriptive name** for the rule to keep your setup organized. Optionally, add a **brief description** explaining its purpose for easier identification later.
Define where the rule should be applied by specifying criteria such as **URL**, **Host**, or **Path**. You can choose from options like **Regex**, **Contains**, **Wildcard**, or **Equals**, or use **Advance Filters** for more precise conditions.
For more details on source conditions, [**read this guide**.](/http-rules/advanced-usage/advance-targeting)
To apply a rule on [our demo website](https://www.requestly-playground.com/), use the following configuration:
* **Condition Type:** URL
* **Operator:** Contains
* **Value:** `requestly-playground.com`
This example targets any requests made to the [**Requestly Interceptor Play**](/http-rules/advanced-usage/advance-targeting)[**ground**](https://requestly-playground.com), ensuring the script is applied wherever the URL contains `requestly-playground.com`.
You have **two options** for the code source:
1. **Custom Code:** Directly paste your script or CSS into the editor (used in the examples below).
2. **URL:** Provide a link to an external file containing the script or CSS.
In the **URL** option, add a link to an external file containing the script or CSS.
> **You can also pick the response from the Requestly Interceptor File Server using the** `Pick from File Server` **feature.** This allows you to inject scripts or JSON responses hosted on the File Server directly into your rule.
In the **Custom Code** option, you can directly paste your script or CSS into the editor.
Here, we are using **Custom Code** as it allows you to easily add and test your code directly.
You can add either CSS styles or JavaScript code:
**To Add CSS Styles→** Insert the following code to modify the web page's styling:
```xml theme={null}
```
This code changes the background colour of product cards to a light green (`#e0ffe5`) and adjusts the product images' blend mode.
You can also import this rule and apply it directly by using this\
→**shared list**
**Add JavaScript Code →** Insert the following script to display an alert message:
```xml theme={null}
```
This JavaScript code triggers an alert with the message `Script injected successfully!` to confirm the rule is active.
You can also import this rule and apply it directly by using this\
→ **shared list**
While injecting JavaScript, you can enhance the `
```
If you are injecting **CSS**, it is applied automatically as soon as the rule is executed.
This option is available **only when injecting JavaScript**
* **As Soon As Possible:** The script will be injected as soon as the page starts loading.
* **After Page Load:** The script will be injected after all page content has fully loaded
Once you are satisfied with your configuration, click **Save** to store the rule. After saving, make sure to toggle the rule **ON** to activate it. This will apply the rule.
There are multiple ways to validate if a rule is applied or not, learn more about how to `validate rule execution`**.**
To ensure the rule is working correctly, click the **Test** button and enter the URL of the page where you want to apply this rule.
A confirmation widget will appear to indicate if the rule has been successfully applied.
Here, you can see that the rule has been applied, and an alert displays the message **Script Injected Successfully.**
`OR`
Here, you can see that the rule has been applied, and the styles defined in the CSS are applied to the page.
# Map Local
Source: https://interceptor-docs.requestly.com/http-rules/rule-types/map-local
Use the Map Local feature in Requestly Interceptor to instantly test local file changes by serving them as live responses for intercepted requests.
***
The **Map Local** feature in Requestly Interceptor enables you to serve any local file as the response for an intercepted request in real time. This is particularly useful for testing, as you can modify the local file and immediately see the changes without deploying them to a server.
This feature is only available in the `Requestly Interceptor Desktop App`.
## Why Use Map Local?
* **Map Production JS/CSS/HTML Files to Local Files**: Test and debug changes to production assets by mapping them to local versions, ensuring seamless updates before deployment.
* **Create Mock APIs Using Local Files**: Simulate API responses by serving local JSON or other data files, allowing for more flexible and controlled testing.
## How to Create a Map Local
Using **Map Local**, you can replace a server response with a local file. Follow these steps:
Download and install the Requestly Interceptor Desktop App to access the **Map Local** feature.
Open the Requestly Interceptor Desktop app and click **Connect Apps** to establish the connection. Then, select your browser and open it. Once the browser is open, go to the website where you want to use the **Map Local** feature.
In the **Network Traffic** table of the Requestly Interceptor app, locate the request you want to modify (e.g., `https://example.com`). Right-click on it and choose **Redirect URL (Map Local/Remote)**.
Requestly Interceptor serves the local file in real-time. Any changes made to the file are immediately reflected in the responses, eliminating the need to update the rule.
Choose the **Map Local** option in **Redirects to** and browse your system to select the local file that should replace the server’s response.
This file will now be used instead of the original request’s response.
Click **Save Rule** to save the configuration.
Reload the website to see the local file replacing the server response in real time. Ensure the rule is **enabled** so it remains active and correctly applied.
There are multiple ways to validate if a rule is applied or not, learn more about how to `validate rule execution`**.**
# Map Remote
Source: https://interceptor-docs.requestly.com/http-rules/rule-types/map-remote
The Map Remote feature allows redirection of network requests to alternate destinations, facilitating transparent testing, debugging, and API version management.
***
The Map Remote feature allows you to redirect the location of a network request to a new destination, enabling the response to be transparently served from this new location as though it were the original destination.
## Why Use Map Remote?
The Map Remote feature is particularly useful in the following scenarios:
* **Testing Local Changes on Production Sites:** Use development or staging endpoints in place of production ones without modifying the source code, allowing for seamless testing of local code.
* **Domain Switching:** Redirect traffic to a local environment for testing purposes, such as evaluating changes before deployment.
* **HTTP to HTTPS Mapping:** Easily switch between HTTP and HTTPS destinations for secure testing.
* **API Backward Compatibility:** Test the backward compatibility of new API versions by mapping requests to a different API version
## How to Use Map Remote
In Requestly Interceptor, there are 2 ways you can implement a Map Remote configuration. You can utilize the two rule types: **Redirect Request** and **Replace Rule**.
### Redirect Request
The Redirect rule enables you to specify a complete URL to which a network request should be redirected. This is particularly helpful for direct mappings of entire endpoints or domains.\
→ [Learn how to create a Redirect Request rule.](/http-rules/rule-types/redirect-rule)
### Replace Rule
The Replace rule allows you to substitute a specific part of a URL with another string. This provides greater flexibility for partial URL adjustments, such as replacing a subdomain or path segment.\
→ Learn how to create a Replace Rule.
There are multiple ways to validate if a rule is applied or not, learn more about how to `validate rule execution`**.**
# Modify Headers
Source: https://interceptor-docs.requestly.com/http-rules/rule-types/modify-headers
Modify HTTP request and response headers with Requestly Interceptor for Free. Learn how to add, remove, or override headers for debugging, testing, and customizing API requests.
***
HTTP(s) Headers are key-value pairs that pass additional information with HTTP(s) requests or responses. This document explains how developers can use Requestly Interceptor to modify these headers by adding, removing, or overriding values easily.
## Why Use the Modify Headers Rule
* **Open Websites in an iframe for Testing:** Headers like `X-Frame-Options` and `Content-Security-Policy` prevent pages from being opened in iframes to avoid clickjacking. Use Requestly Interceptor to modify these headers for testing purposes.\
Learn more →
* **Remove Content-Security-Policy:** The `Content-Security-Policy` header restricts the injection of external scripts. Requestly Interceptor can remove this header for testing purposes.\
Learn more →
* **Debugging CORS Issues:** To resolve CORS errors in browsers, modify response headers such as `Access-Control-Allow-Origin`, `Access-Control-Allow-Methods`, `Access-Control-Allow-Headers`, and `Access-Control-Allow-Credentials`.\
Learn more →
## Steps to Create Header Rules
Navigate to the **HTTP Rules** section and click on `+ New Rule` and select the `Modify Headers` option.
Provide a **descriptive name** for the rule to keep your setup organised. Optionally, add a brief **description** explaining its purpose for easier identification later.
Add conditions using **Source Condition** and **Source Filters** to target specific requests. Conditions can include URL, Host, or Path with matching options such as **Regex**, **Contains**, **Wildcard**, or **Equals**.
Let’s use an echo endpoint that returns request headers, body, query params etc as JSON response.\
Endpoint → `https://echo-http-requests.appspot.com/echo`
In this step, you can select the option to modify. It rule allows you to edit both the request and the response headers.
Specify key-value pairs to add, remove, or override headers. If you want to **Modify** **Request Headers**, add values under the Request headers tab.
Specify key-value pairs to add, remove, or override headers. If you want to **Modify Response headers**, add values under the Response headers tab.
Once you are satisfied with your configuration, click `Save` to store the rule. After saving, make sure to toggle the rule `ON` to activate it. This will apply the rule and ensure it works as expected.
There are multiple ways to validate if a rule is applied or not, learn more about how to [`validate rule execution`](/http-rules/advanced-usage/validate-rules-execution).
Test the rule by opening the URL \[[`https://echo-http-requests.appspot.com/echo`](https://echo-http-requests.appspot.com/echo)] in a new tab to see the changed header values.
Test by sending a request from the Requestly Interceptor web app.
***
## What's Next?
Learn to modify API request payloads
Simulate different API responses for testing
Keep your rules organized with groups
# Modify Query Params
Source: https://interceptor-docs.requestly.com/http-rules/rule-types/modify-query-params
Learn to modify query parameters in Requestly Interceptor. Add, remove, or override URL query params with custom rules.
***
Using Requestly Interceptor, you can modify the query parameters (query params) sent to the server. This includes adding new query params, updating the values of existing params, or removing specific or all query params from the URL. The following sections explain the steps and common scenarios for modifying query params.
## Why Use Modify Query Parameters Rule
1. **Remove UTM Tracking Parameters**: Automatically strip out UTM tags from URLs to ensure cleaner analytics data.
2. **Burst Cache Using Query Params**: Append a versioning query param (e.g., `?v=2`) to the URL to bypass caching and fetch fresh data.
3. **Send Additional Information to APIs**: Add custom parameters to API calls, such as indicating internal testing (e.g., `?testing=true`).
## How to Modify Query Params
Navigate to the HTTP Rules section in the Requestly Interceptor web or desktop app. Click on the `+ New Rule` button and select `Modify Query Params` from the list of options.
Provide a **descriptive name** for the rule to keep your setup organised. Optionally, add a **description** to explain the purpose of the rule for easier identification.
For example, a name like `Remove UTM Tags` can help quickly understand the rule’s objective.
Source Condition specifies the criteria for matching requests. You can target requests using the following attributes:
* **URL, Host, or Path**: Define what part of the request should be matched.
* **Operators**: Choose from Regex, Contains, Wildcard, or Equals to apply precise matching logic.
For more detailed guidance, refer to the [Source Conditions Guide](/http-rules/advanced-usage/advance-targeting).
You can target URLs containing `?utm_` to remove UTM tracking parameters. These source conditions ensure the rule activates only for relevant requests.
* **Add Query Params**: Specify the key and value to be appended to the URL.
* **Remove Query Params**: Enter the names of query parameters to delete, or select the option to remove all parameters.
* **Override Query Params**: Update an existing parameter’s value by specifying its key and new value. This flexibility lets you customize query parameters for various scenarios like versioning or testing.
Click **Save** to store the rule and toggle it **ON** to activate. Activating the rule ensures it applies to all requests matching the defined source conditions, dynamically modifying URLs as specified.
Use the Test option to verify the rule’s functionality. Enter a test URL to view the modified URL with applied changes in query parameters. This helps confirm the rule’s effectiveness before deployment.
There are multiple ways to validate if a rule is applied or not, learn more about how to `validate rule execution`**.**
# Modify Request Body
Source: https://interceptor-docs.requestly.com/http-rules/rule-types/modify-request-body
Learn to modify HTTP request payloads with static data or JavaScript. A guide to setting up rules for testing APIs, handling GraphQL, and debugging payloads.
***
The Modify Request Body rule enables you to override or programmatically modify the data sent to the server in an HTTP request body. This rule is particularly useful for debugging, testing, and dynamically altering API payloads.
## Why Use the Modify Request Body Rule?
* **Static Request Body Modification**: Replace the request body with predefined static data for consistent testing.
* **Programmatic Request Body Modification**: Dynamically modify the request payload using JavaScript based on specific conditions.
* **Testing Edge Cases**: Simulate unsupported or erroneous fields in request payloads to evaluate server responses.
* **Send Additional Data**: Include extra fields in the payload for enhanced server communication, especially for GraphQL queries or APIs.
## How to Configure the Rule
Navigate to the HTTP Rules tab in the web or desktop app. Click on `+ New Rule` and select `Modify Request Body` from the options.
Provide a **descriptive name** for the rule to keep your setup organized. Optionally, add a brief **description** explaining its purpose for easier identification later.
Choose the resource type for modification:
* **REST API**: Modify `XHR/Fetch` requests initiated by web pages.
* **GraphQL**: Target and modify GraphQL APIs by operation.
Define the criteria for the rule to be applied, such as **URL**, **Host**, or **Path**. Choose from **Regex**, **Contains**, **Wildcard**, or **Equals**, or use Advance Filters for more precise conditions.
For more detailed guidance, refer to the Source Conditions Guide.
* **Condition Type**: URL
* **Operator**: Contains
* **Value**: `api.example.com`
If targeting GraphQL APIs, filter queries by their operation name. Add the **Payload JSON Key** (e.g., `operationName`) and specify the corresponding **Value** (e.g., `getUsers`) to target specific GraphQL operations
You can override a request body using a static JSON or programatically using JS.
**Static Request Body**
Enter the static JSON payload you want to forward to the server.
```json theme={null}
{
"key": "value",
"feature": "modify-request"
}
```
**Dynamic Request Body**
Use JavaScript to dynamically modify the request payload based on attributes such as HTTP method, URL, or the original request body. You can use following properties:
`method (string)`: The HTTP method of the request (e.g., GET, POST, PUT, DELETE).
`url (string)`: The full URL of the request.
`body (string)`: The original request body as a raw string.
`bodyAsJson (object)`: The original request body parsed into a JSON object.
Example:
```typescript theme={null}
function modifyRequestBody(args) {
const { method, url, bodyAsJson } = args;
let newBody = bodyAsJson;
if (method === "POST") {
newBody["feature"] = "modify-request";
}
return newBody;
}
```
`Return`
You can `return` modified body as `string` or `JSON` object.
You can also use Dynamic Data to override GraphQL APIs by detecting the operation name in the request body.
Click **Save** to store the rule and toggle it **ON**. This will apply the rule to the defined source conditions.
Modified request bodies will not appear in browser network devTools due to technical constraints but will still be applied to the actual request sent to the server.
To ensure the rule is working correctly, click the `Test` button and enter the URL of the page where the matching URL is called. This will open the webpage in a new tab, with a widget showing the status of applied rules.
There are multiple ways to validate if a rule is applied or not, learn more about how to `validate rule execution`**.**
## Shared State for Advanced Modifications
You can store and retrieve data within and across Modify Request and Modify Response rules using shared state in programmatic JavaScript mode.\
→ Learn more about shared state.
# Modify API Response
Source: https://interceptor-docs.requestly.com/http-rules/rule-types/modify-response-body
Learn how to modify API responses in Requestly Interceptor with Dynamic Modification. Simulate edge cases, test with custom data, and create API mocks for faster front-end development and QA workflows
***
The **Modify API Response Rule** in Requestly Interceptor allows developers to modify API responses directly without requiring back-end access. It is often used to simulate edge cases, replicate bugs, and support QA workflows. With **Dynamic Modification**, developers can use JavaScript to conditionally alter responses based on the original request or server response
## Why Use Modify API Response Rule?
Modify API Response Rules are useful in several scenarios:
* **Frontend Development**: Work seamlessly even if the backend is unavailable or incomplete.
* **Custom Testing**: Test application behaviour with modified or custom data.
* **Error Simulation**: Trigger specific errors by modifying response status codes.
* **Backend Independence**: Make changes to API responses without requiring backend changes.
This rule can also be used to create API Mocks that are beneficial during development and QA cycles.
## Steps to Configure a Modify API Response Rule
Navigate to the HTTP Rules section in the Requestly Interceptor app. Click `+ New Rule` and choose the `Modify API Response` option.
Choose the resource type for modification:
* **REST API**: Modify `XHR/Fetch` requests initiated by web pages.
* **GraphQL**: Target and modify GraphQL APIs by operation.
* **HTML/JS/CSS (Desktop App Only)**: Modify static files for desktop applications.
Define the criteria for the rule to be applied, such as **URL**, **Host**, or **Path**. Choose from **Regex**, **Contains**, **Wildcard**, or **Equals**, or use **Advance Filters** for more precise conditions.
For more detailed guidance, refer to the **Source Conditions Gui**[**de**.](/http-rules/advanced-usage/advance-targeting)
If targeting GraphQL APIs, filter queries by their operation name. Add the **Payload JSON Key** (e.g., `operationName`) and specify the corresponding **Value** (e.g., `getUsers`) to target specific GraphQL operations.
Modify the status code of the response using the dropdown menu. Choose from:
* `2XX` for successful responses
* `4XX` for client errors
* `5XX` for server errors
If left empty, the original status code remains unchanged.
Choose one of the following methods to modify the response data:
* **Static Response Modification**: Input a static value as the response body.
* **Dynamic** **Modification Script (JavaScript)**: Use JavaScript to modify responses dynamically. The script provides access to parameters like:
* `method`: HTTP Method (GET, POST, etc.)
* `url`: Full URL of the request
* `response`: Original response body (string)
* `responseType`: Content type of the original response
* `requestHeaders`: Headers sent with the request
* `responseJSON`: Original response parsed as a JSON object
**Example:**
```jsx theme={null}
function modifyResponse({ responseJSON }) {
responseJSON.modifiedKey = "modifiedValue";
return responseJSON;
}
```
You can store and retrieve data within and across Modify Request and Modify Response rules using shared state in programmatic JavaScript mode.\
→Learn more about shared state here.
*
You can check the “Serve this response body without making call to the server” checkbox as the label suggests it will ensure you get the response locally without hitting your API server.
Click **Save** to store the rule and toggle it **ON**. This will apply the rule to the defined source conditions.
This feature is available on the browser extension only.
To ensure the rule is working correctly, click the `Test` button and enter the URL of the page where you want to apply this rule. This will open the webpage in a new tab, with a widget showing the status of applied rules.
There are multiple ways to validate if a rule is applied or not. Learn more about how to `validate rule execution`**.**
Changes applied by this rule won’t appear in browser devtools due to technical constraints, but are sent with the actual requests.
**Serve local files**
Replace API, HTML, JS, or CSS responses with local files. Changes to the file are reflected in real-time, no need to update the rule.
**Override HTML/JS/CSS**
Intercept and modify static assets like HTML, JavaScript, and CSS. Useful for testing UI changes without touching production code.
# Modify User Agents
Source: https://interceptor-docs.requestly.com/http-rules/rule-types/modify-user-agents
Learn how to modify User-Agent strings in HTTP headers with Requestly Interceptor. Test websites on different devices or browsers, debug compatibility issues and refine content delivery.
***
Servers commonly use the **User-Agent** Request Header to identify their client's application type, operating system, software vendor, or software version. Based on the User-Agent string, the server selects suitable content to send in response. For instance, when a website opens on a mobile device, it usually looks quite compact and different from the way it opens on a desktop.
By modifying the User-Agent string, you can control how a website interprets the client accessing it. This capability is especially useful for testing and debugging applications to observe how they respond to different devices and browsers.
## Benefits of Modifying User Agents
* **Device-Specific Testing**: View and test mobile, tablet, or desktop versions of a website.
* **Browser Compatibility Checks**: Analyse how your application behaves in different browsers.
* **Debugging**: Verify if content adapts correctly based on User-Agent information.
## How to Modify User Agents in Requestly Interceptor
Navigate to the HTTP Rules section in the Requestly Interceptor app. Click on the `+ New Rule` button and select `User-Agent` from the available options.
Provide a **meaningful name** for the rule to keep your setup organized. Optionally, add a brief **description** to explain its purpose for easier identification later.
Define where the rule should be applied by specifying criteria such as **URL**, **Host**, or **Path**. You can choose from options like **Regex**, **Contains**, **Wildcard**, or **Equals**, or use **Advance Filters** for more precise conditions.
For more details on source conditions, [**read this guide**.](/http-rules/advanced-usage/advance-targeting)
Choose whether you want to emulate a specific device or browser. Requestly Interceptor provides preset options such as Android Phones, iPhones, or popular web browsers like Internet Explorer or Safari.
Select the exact version or model you wish to emulate. You can either choose from the predefined options or define a custom User-Agent string to meet your testing needs.
Once all conditions are set, click Save to store the rule. Toggle the rule ON to activate it. You can now test your setup by visiting the targeted websites.
## Examples of User-Agent Strings
* **Android Device**: `Mozilla/5.0 (Linux; Android 10; SM-G960F) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Mobile Safari/537.36`
* **iPhone**: `Mozilla/5.0 (iPhone; CPU iPhone OS 14_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1 Mobile/15E148 Safari/604.1`
* **Desktop Chrome**: `Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36`
## Test Your Rule
There are multiple ways to validate if a rule is applied or not, learn more about how to `validate rule execution`**.**
Use the Test feature in Requestly Interceptor to confirm the rule's behavior. Input the URL of a website and monitor how the content adapts to the new User-Agent string. This ensures that the desired changes are applied successfully.
The mobile version of the spreadsheet is loaded on the desktop.
# Redirect Request
Source: https://interceptor-docs.requestly.com/http-rules/rule-types/redirect-rule
Learn how to use Requestly Interceptor's Redirect Rule for testing, debugging, and development, with step-by-step guides and use cases.
***
The **Redirect Request Rule** in Requestly Interceptor allows you to seamlessly redirect HTTP requests to a different URL or resource. This is particularly useful for testing, debugging, or even for creating workarounds during development.
## Why Use the Redirect Rule?
1. **Redirect Production to Local Environment:** Map your production scripts or APIs to your local running code and test your local code directly on production sites without deployment.\
Learn more →
2. **Test API version changes**: If a new API version is available, you can test backward compatibility by setting up a redirect rule to point all URLs from the old version to the new one. This lets you test the upgrade without modifying your code.\
Learn more →
3. **Swap Javascript from production to staging/dev environment:** Test your dev implementation in tag manager scripts like Adobe DTM, Tealium Tag, and Google Tag Manager Containers before pushing them live on client websites.
Learn more →
## **How to Configure the Redirect Rule**
Navigate to the HTTP Rules tab in the web or desktop app. Click on `+ New Rule` and select `Redirect Rule` from the options.
Provide a **descriptive name** for the rule to keep your setup organised. Optionally, add a **brief description** explaining its purpose for easier identification later.
Define where the rule should be applied by specifying criteria such as **URL**, **Host**, or **Path**. You can choose from options like **Regex**, **Contains**, **Wildcard**, or **Equals**, or use Advance Filters for more precise conditions.
For more details on source conditions, [read this guide](/http-rules/advanced-usage/advance-targeting).
For this example, we are using the Requestly Interceptor Playground (a demo eCommerce Store) to demonstrate the `Redirect Request` rule. This gives you a near-live experience of how the rule works.
In this case, we are targeting API requests that fetch data for the page, specifically those with query parameters like `type.slug:bakery`.
* **Condition Type:** URL
* **Operator:** Contains
* **Value:** `https://rest.requestly-playground.com/api/products?searchJoin=and&with=type%3Bauthor&limit=30&language=en&search=type.slug:bakery%3Bstatus:publish`
Set the target URL to which requests should be redirected. You can use the following options:
To redirect requests from one API endpoint to another, set the following:
* **Source URL**: `https://rest.requestly-playground.com/api/products?searchJoin=and&with=type%3Bauthor&limit=30&language=en&search=type.slug:bakery%3Bstatus:publish`
* **Redirect Target**: `https://rest.requestly-playground.com/api/products?searchJoin=and&with=type%3Bauthor&limit=30&language=en&search=type.slug:gadget%3Bstatus:publish`
In this case, we are changing the query parameter `type.slug:bakery` in the **Source URL** to `type.slug:gadget` in the **Redirect Target**. This redirects requests for bakery products to a new endpoint for tech products.
You can also import this rule and apply it directly by using this shared list**.**
> The local file option is available only in the [desktop app](https://requestly.com/downloads).
To redirect an API request to a local file, choose **File from your device** as the redirect target. This will serve the response from your local file instead of the live server.
You can redirect API requests to a custom response hosted on **Requestly Interceptor’s File Server**.
Choose from an existing **JSON file** or upload a new one.
Once selected, the request will return the hosted response instead of hitting the live server.
Once you are satisfied with your configuration, click `Save` to store the rule. After saving, make sure to toggle the rule `ON` to activate it. This will apply the rule and ensure it works as expected.
To verify that the rule is working, click the `Test button`, enter a relevant URL, and then click `Test Rule`.
You can use the following URL to test the redirection: `https://www.requestly-playground.com/?rq-category=redirect`.
There are multiple ways to validate if a rule is applied or not, learn more about how to `validate rule execution` .
# Replace String Rule
Source: https://interceptor-docs.requestly.com/http-rules/rule-types/replace-strings
Learn how to modify URLs, query parameters, or content dynamically with Requestly Interceptor's Replace String Rule. Test and debug changes without altering your code.
***
The **Replace String Rule** in Requestly Interceptor allows you to modify the content of HTTP requests and responses, making it easy to test, debug, or apply fixes dynamically without modifying your original codebase. This feature is useful for replacing URLs, headers, or specific content in requests and responses.
## Why Use the Replace String Rule?
1. **Switch Domains:** To test your app with the new changes done on the local server, you can use replace `your-app-server.com` with `localhost` using Replace String Rule. In this way, you can test your app without having to change any of your code.\
Learn more →
2. **Change Query Parameter Values:** You can change the values of query parameters present in a URL.\
For example: Changing `?dl-0` to `?dl=1` in a Dropbox URL downloads the file directly without going to the usual preview page.\
Learn more →
## **How to Configure the Replace** String **Rule**
Navigate to the **HTTP Rules** tab in the Requestly Interceptor web or desktop app. Click on `+ New Rule` and select the `Replace String` option.
Provide a **descriptive name** for your rule to keep things organised. Optionally, add a **brief description** to explain its purpose for easy identification later.
Define the criteria for the rule to be applied, such as **URL**, **Host**, or **Path**. Choose from **Regex**, **Contains**, **Wildcard**, or **Equals**, or use Advance Filters for more precise conditions.
For more detailed guidance, refer to the Source Conditions Guide.
For this example, we are using the [**Requestly Interceptor Playground**](https://requestly-playground.com/) to demonstrate the `Replace Request` rule. This gives you a near-live experience of how the rule works. In this case, we are targeting API requests that fetch product data.
To replace the API endpoint to fetch products
* **Condition Type:** URL
* **Operator:** Contains
* **Value:** `https://rest.requestly-playground.com/api/products`
In this step, configure the **Replace String Rule** with the following two sections:
1. **Replace**: Define the part of the URL you want to replace. This could be the hostname, query value, or any specific part of the URL.
Example: `type.slug:bakery`
2. **With**: Specify the value or string that will replace the original part of the URL.
Example: `type.slug:grocery`
This rule ensures that any requests matching the given criteria will have the specified URL part replaced dynamically.
Once satisfied with your setup, click **Save** to store the rule. Don’t forget to toggle it **ON** to activate it and apply the changes.
To verify the rule works as expected, click the **Test** button, enter a relevant URL, and then click **Test Rule**.
You can use the following URL to test the redirection: [https://www.requestly-playground.com/?rq-category=replace](https://www.requestly-playground.com/?rq-category=replace)
There are multiple ways to validate if a rule is applied or not, learn more about how to `validate rule execution`.
# Sharing
Source: https://interceptor-docs.requestly.com/http-rules/sharing
Simplify your workflows by sharing and managing rules effortlessly within your team or across your devices. Requestly Interceptor provides tools to make it seamless. Explore different ways to share your rules:
Collaborate efficiently by sharing your rules directly within your workspace. Your team can access, edit, and use the shared rules without hassle.
Create a shared list to combine multiple rules and share them easily via a single link
Download your rules as a file and use them offline or share them externally with your team and collaborators
# Download Rules
Source: https://interceptor-docs.requestly.com/http-rules/sharing/download-rules
Learn how to download HTTP rules for sharing as files.
***
Downloading HTTP rules allows you to save them locally for offline use or share them as files with others. This feature provides flexibility for scenarios where direct sharing through workspaces or Shared Lists is not possible.
## Why Use the Download Option?
* **Internal Documentation:** Maintain a local copy for internal documentation or historical reference.
* **Reusable Templates:** Use the downloaded rules as templates for creating similar configurations in other environments or projects.
* **Automation:** Automate workflows by integrating the downloaded file using Requestly Interceptor's public API.
* **Backup Storage:** Safeguard your rules by keeping a backup that can be re-imported when needed.
* **Flexible Sharing:** Share the file with external collaborators who may not have direct access to your workspace or Shared Lists.
## Steps to Download Rules
Go to HTTP Rules, and open "My Rules" from the left sidebar. Select the rules you wish to download by checking the boxes next to the rules.
Click on the "Share" button located in the toolbar appear after selecting rules. This action will open the Share modal. Switch to the Download tab.
Click on the “Download rule” button to download a JSON file having all the selected rules.
## Steps to Import Rules
Go to HTTP Rules, open "My Rules" from the left sidebar, and click on the "Import" button in the toolbar.
Select the downloaded file from your device and upload it using the import dialog.
Review the rules in the preview section and click "Import" to add them to your workspace.
# Share in Workspace
Source: https://interceptor-docs.requestly.com/http-rules/sharing/share-in-workspace
Learn to share HTTP rules in workspaces, create workspaces, invite members, and manage rules.
***
Sharing rules within workspaces is a powerful feature that ensures consistency and real-time collaboration among team members. By sharing rules across workspaces, you eliminate redundancy and maintain synchronized updates, creating a seamless development environment.
## Overview of Team Workspace Collaboration
Team Workspace is a collaborative platform where team members can access, edit, and share rules in real-time. When you share rules in a workspace:
* All users in the workspace will have access to the shared rules.
* Changes made to the rules are immediately reflected for all users.
* You can transfer rules between existing workspaces or create new workspaces for specific projects or teams.
Team Workspaces provide a collaborative platform for managing and sharing rules across your team.
## Steps to Share Rules in Workspaces
Go to HTTP Rules, and open "My Rules" from the left sidebar. Identify the rules you wish to share by selecting them from the rules table. Use the checkboxes provided to choose one or multiple rules simultaneously.
Click on the "Share" button located in the toolbar appear after selecting rules. This action will open the Share modal.
In the Share modal, switch to the "Share in Workspace" tab. Here, you have the following options:
**Copy to a Different Workspace**
You will see a list of workspaces you have access to, and you can click on the "Copy here" link next to a workspace to copy the selected rules to that workspace.
**Invite Users to the Current Workspace**
Add new collaborators to the current workspace by inviting them via email. They will gain access to all existing workspace rules, enabling real-time collaboration.
### Key Advantages of Sharing Rules in Workspaces
* **Real-Time Updates:** Any modifications to shared rules in a workspace are instantly available to all users.
* **Centralized Collaboration:** Workspaces act as a single source of truth for all shared rules, simplifying team workflows.
* **Flexibility:** Easily transfer rules across workspaces or create new collaborative environments tailored to specific needs.
# Shared List
Source: https://interceptor-docs.requestly.com/http-rules/sharing/shared-list
Learn to create and share a Shared List for distributing HTTP rules with controlled access.
***
A Shared List is a convenient way to share HTTP rules using a single shareable link. You can create a Shared List for team collaboration or distribution while maintaining control over accessibility.
## Key Features of Shared Lists
* **Simple Sharing:** Share multiple rules via a single link.
* **Controlled Access:** Public or private options ensure flexibility in accessibility.
* **Static State:** Shared Lists share the current state of rules and **do not update** in real-time.
## Steps to Create a Shared List
Go to HTTP Rules, and open "My Rules" from the left sidebar. Select the rules you want to share by using the checkboxes in the rules table.
Click on the "Share" button in the toolbar above the rules table. In the "Shared List" tab of the Share modal, you can define the accessibility of the Shared List:
1. **Public Shared List:** The link is automatically generated; just copy the link and share it with anyone to allow them to view and import the Shared List.
2. **Private Shared List:** Requires you to add specific email addresses for users who can view and import the Shared List. After entering the email IDs, click on "Create List." An email is sent to the user, and additionally, you can copy the generated link and share it with the person. They need to log in using the same email to import the Shared List.
You can get the shared list import email when someone imports your shared list.
For existing shared lists, you can click on more options on shared list row and enable or disable it from there.
## Steps to Import a Shared List
Importing a Shared List differs between the browser extension and the desktop app, with specific steps for each platform.
### Import in Browser Extension
If you have received a Shared List link, open it in your browser. Try opening this demo Shared List.
Click on the `View` button to review the rules in the Shared List before importing.
Click on "Import to My Rules" to add the Shared List rules to your dashboard.
### Import in Desktop App
Go to HTTP Rules, and open "Shared List" from the left sidebar. Click "Import from URL."
Paste the Shared List link into the input box. Click "Import Rules from this list" to view the Shared List content. Review the rules and click "Import to My Rules" to add them to your dashboard.
Unlike sharing in workspaces, Shared Lists do not reflect real-time updates. To collaborate with live updates, consider using the "Share in Workspace" feature.
# Charles Proxy
Source: https://interceptor-docs.requestly.com/imports/charles-proxy
Learn how to export Charles Proxy configurations and import them into Requestly Interceptor.
***
Charles Proxy is a popular debugging tool for monitoring and managing network traffic. Requestly Interceptor can import configurations exported from Charles Proxy, enabling you to use your existing Charles Proxy rules and settings directly within Requestly Interceptor. Step-by-step instructions are outlined below for exporting configurations from Charles Proxy and importing them into Requestly Interceptor.
Requestly Interceptor supports Rewrite, Map Local, Map Remote, No Caching, Block lists & Block Cookies configuration imports from Charles Proxy.
## Exporting Configurations from Charles Proxy
Follow the steps below to export your configurations from Charles Proxy:
### Step 1: Access Import/Export Settings
From the Charles top menu bar, select **Tools > Import/Export Settings**.
### Step 2: Select Tools to Export
A new popup window will open. Switch to the **Export** tab. Under the **Tools** section, select the tools you want to export. Click on the **Export** button located in the bottom-right corner.
To export a single rule, follow the same process, but select only the specific configuration you wish to export.
## Importing Configurations into Requestly Interceptor
After exporting your configurations from Charles Proxy, follow these steps to import them into Requestly Interceptor:
### Step 1: Open Import from Charles
For the web app, you can directly open ***import from Charles screen***.
Navigate to the HTTP Rules section.
If no rules exist, the **Import from Charles** option will be displayed. Click it to open the import popup.
If you already have rules, click the **Import** button located in the top-right corner and select the **Import from Charles** option from the bottom of the popup.
### Step 2: Upload the Exported File
Drop or select your exported Charles `.xml` file on the import page.
### Step 3: Review Imported Rules
On successful import, the Charles Proxy tool settings will appear as Requestly Interceptor rules. Your rules will be grouped in Requestly Interceptor according to the tool name from Charles Proxy.
# Header Editor
Source: https://interceptor-docs.requestly.com/imports/header-editor
Learn how to export Header Editor configurations and import them into Requestly Interceptor.
**Header Editor** is a Chrome extension used to modify HTTP request and response headers directly in the browser. If you're switching to **Requestly Interceptor**, a free, modern, and collaborative alternative, this guide will help you migrate your Header Editor configuration seamlessly.
With Requestly Interceptor, you get powerful and user-friendly tools for header modification completely free of charge.
Requestly Interceptor does not support the import of **"Modify Response Body"** configurations from Header Editor.
## Exporting Configuration from Header Editor
Click on the **Header Editor** icon in your browser’s extensions toolbar and click on manage.
Once the extension interface opens, go to the **Export and Import** tab in the sidebar.
Click on the **Export** button. This will **download** your current Header Editor configuration.
## **Importing Configurations into Requestly Interceptor**
After exporting your configurations from Header Editor, follow these steps to import them into Requestly Interceptor:
If you **don’t have any existing rules**, you’ll see an **Import from Header Editor** option directly on the screen. Click it to open the import popup.
If you **already have rules**, click the **Import** button in the top-right corner, then select **Import from Header Editor** from the bottom of the popup.
On the import page, **drag and drop** your exported config `.txt` , or **click to browse and select it** from your system.
Once the file is processed successfully, your Header Editor configurations will be automatically converted into Requestly Interceptor rules. Review and confirm them in your dashboard.
# Modheader
Source: https://interceptor-docs.requestly.com/imports/modheader
Learn how to export ModHeader Profiles and import them into Requestly Interceptor.
***
ModHeader is a browser extension commonly used to modify HTTP headers for testing and debugging purposes. Requestly Interceptor supports importing your profiles from ModHeader as HTTP Rules. Follow the steps below to export your profiles from ModHeader and import them into Requestly Interceptor.
## Watch the Video Tutorial
Here's a step-by-step walkthrough of how to export from ModHeader and import into Requestly Interceptor
## Exporting Profile from ModHeader
### **Step 1: Open ModHeader**
Open the ModHeader extension in your browser to access your configurations.
### **Step 2: Export Profiles**
Click on the **Export** button located in the top bar and select **Export JSON**. Choose the profiles you want to export.
### **Step 3: Download JSON File**
Click on **Download JSON** to save the file to your device for later import.
## Importing Configurations to Requestly Interceptor
### **Step 1: Navigate to the Import Option**
For the web app, you can directly open `Import from ModHeader screen`.
If no rules exist, the **Import from ModHeader** option will be displayed. Click it to open the import popup.
If you already have rules, click the **Import** button located in the top-right corner and select the **Import from ModHeader** option from the bottom of the popup.
### **Step 2: Upload JSON File**
Follow the on-screen instructions to upload the JSON file you downloaded from ModHeader.
Newly imported rules will be available under HTTP Rules.
# Resource Override
Source: https://interceptor-docs.requestly.com/imports/resource-override
Learn how to migrate your configurations from Resource Override Chrome Extension to Requestly Interceptor
## **Import Resource Override Configurations**
Instead of manually setting up rules, you can quickly import your Resource Override configuration and apply them with a few simple steps.
Open your browser’s DevTools and navigate to the “Override” option.
Click on the “Options” menu and then click “Save Rule” to download your current rule configuration.
Go to the Requestly Interceptor dashboard and navigate to the **HTTP Rules** section.
For the web app, you can directly open `Import from Resource Override`.
Click the **Import** button in the HTTP Rules section. Choose “Resource Override” from the available import options.
Upload the saved configuration file you downloaded earlier and click on the **Import rules** button, and your rules will be applied to your Requestly Interceptor setup
Once you confirm, click on the **Import** button, and your rules will be applied to your Requestly Interceptor setup.
## **Resource Override Features Comparison**
Learn more about equivalent features of Requestly Interceptor that you were used in Resource Override.
### **URL → URL**
Every request URL is compared with the *Match URL* and is redirected to the *Replace URL* if the match is successful.
**Exact Match**
If your Resource Override configuration is with exact match without using any \* in it.
This becomes a very straightforward setup in Requestly Interceptor. Use the [Redirect Rule](/http-rules/rule-types/redirect-rule) with the "Equals" operator.
**Wildcard Match**
If your Resource Override configuration is a wildcard match with 1 \* in it.
In Requestly Interceptor, Use the "Wildcard" operator and the substituted value should be replaced with `$1`, Alternatively, if you want to modify the request instead of redirecting it, you can use the Replace Rule. The matched portion of the URL can be replaced using `$1`
e.g. In Requestly Interceptor, You will use HTTP Redirect Rule like
**Multiple Wildcard Operators**
If your Resource Override configuration is a wildcard match with multiple \*’s in it.
In Requestly Interceptor, This becomes HTTP Redirect Rule with Wildcard Operator. Each star gets a number from left to right. You can use $\ like $1, \$2 where you want to use the matched values of \*’s.
### URL → File
When you want to load a file in place of the Matched URL.
In Requestly Interceptor, you can use the **Redirect Request Rule** with **Redirects to** option as **Pick from Files/File Server** and then select the file/create a file that you want to load.
### Inject File
In Resource Override, you can select a file(JS/CSS) and inject that into a webpage.
In Requestly Interceptor, you can use Inject Script Rule as below.
### Change Headers
In Resource Override, you can use Change Headers to update the Request or Response Headers.
In Requestly Interceptor, you can use the Modify Headers Rule and similarly configure the rule as below.
# Browser Extension
Source: https://interceptor-docs.requestly.com/interceptor/browser-extension
Learn how to use Browser Extention to intercept HTTP Request and Responses
**Requestly Interceptor’s browser extension** is the simplest way to intercept and modify HTTP requests and responses directly **within your browser**. It’s lightweight, easy to install, and perfect for debugging frontend issues or simulating API responses, without needing to run a local proxy or configure complex setups.
Whether you're a frontend developer testing new **API integrations** or a QA engineer simulating error scenarios, the browser extension gives you powerful tools right in your development environment.
### Key benefits
* **No proxy setup required** – Works entirely within the browser.
* **Quick debugging** – Instantly view, rewrite, or mock API requests.
* **Cross-browser support** – Available for Chrome, Firefox, Edge, and more.
* **Secure and isolated** – Only affects traffic in the browser you install it on.
### When to use the browser extension
Use the browser extension if:
* You only need to intercept traffic from websites or web apps.
* You’re testing frontend behavior and want a quick setup.
* You want to create rules to mock APIs, rewrite URLs, inject scripts, or modify headers.
### How to intercept traffic using the extension
Once the browser extension is installed, you can start intercepting traffic with just a few clicks.
[Follow the Browser Interception guide to get started →](/interceptor/browser-extension/browser-interception)
This guide walks you through launching a connected browser, viewing traffic in the network table, and verifying the proxy setup.
[Requestly Interceptor’s Browser Extension is a lightweight interceptor](/interceptor/browser-interception) that runs directly in your browser. It allows you to intercept, modify, and control both incoming responses and outgoing requests, making it a powerful tool for developers and testers.
## **Browser extension features**
With the browser extension, you can:
* [**Modify requests**](/http-rules/rule-types/modify-request-body) – Change headers, query parameters, or request methods before they’re sent.
* [**Mock responses**](/api-mocking/api-mocking) – Return custom JSON or status codes instead of hitting the real server.
* [**Redirect traffic – Route**](/interceptor/desktop-app-interception) API calls to staging or mock URLs for flexible testing.
* [Inject](/interceptor/desktop-app-interception)[**scripts/styles**](/http-rules/rule-types/insert-scripts) – Add custom JavaScript or CSS into pages on the fly.
Learn more about how to work with browser interceptor [here.](/interceptor/desktop-app-interception)
## Supported Browsers & Profiles
Requestly Interceptor supports all modern browsers, and you can use it with many browsers like Google Chrome, Firefox, and Safari. Here’s a breakdown of the browser support:
* **Chromium-Based Browsers**
Requestly Interceptor is available on all Chrome-based browsers through the Chrome Web Store. This includes Google Chrome, Microsoft Edge, Brave, Opera, and others.
* **Firefox**
We officially support Firefox, ensuring a seamless experience for Firefox browser.
* **Safari (limited support)**
The Requestly Interceptor extension is available for Safari with a smaller feature set today. Full support for HTTP rules is coming soon.
# Browser Interception
Source: https://interceptor-docs.requestly.com/interceptor/browser-extension/browser-interception
Once you’ve installed the Requestly Interceptor browser extension, you can start intercepting, inspecting, and modifying HTTP(S) traffic directly in your browser. This feature is great for testing APIs, debugging frontend issues, and simulating server responses, without touching your backend or deploying changes.
This guide assumes you’ve already installed the [`Requestly Interceptor browser extension`](https://requestly.com/downloads) for your browser. If not, start there.
### Steps to Intercept traffic in Browser DevTools
Right-click on the webpage and click **Inspect**.
Click on the **Requestly Interceptor** tab.
If it is not visible, click on the **>>** button to expand the hidden tabs and then select **Requestly Interceptor**
Once open, this tab will list out all the requests made by your browser. Here, you have two tabs:
If you want to intercept traffic from another browser extension, please use the [Requestly Interceptor Desktop App](/interceptor/desktop-app#desktop-app) instead.
The **Network Traffic** tab displays a network table where all requests and responses from the webpage are listed. This tab provides debugging options such as:
* **Add JavaScript to Page**: Injects custom JavaScript into the webpage.
* **Add CSS to Page**: Applies custom styles to the page.
* **Emulate a Different Device**: Simulates how the page renders on different devices.
Clicking on any request in the network table reveals detailed information, including request headers, request body, and response body. Additionally, users have the option to create a rule directly from the network table for the selected request.
The available rule creation options are:
* **Redirect to Another URL**
* **Replace Host**
* **Replace Part of URL**
* **Delay Request**
* **Cancel Request**
Clicking any of these buttons will take you to the Requestly Interceptor dashboard with some parameters set, Here you can customize and apply your modifications.
# Desktop App
Source: https://interceptor-docs.requestly.com/interceptor/desktop-app
Learn how to use the Requestly Desktop App to intercept traffic from browsers, Android, iOS, Node.js, terminal, and system-wide proxy.
Requestly Interceptor’s Desktop App is a powerful standalone interceptor that operates as a web proxy, giving you complete control over network traffic across all applications. It allows you to intercept, modify, and inspect both requests and responses, making it an essential tool for developers and testers working beyond the browser environment.
### Supported Platforms
* [**Browsers**](/interceptor/desktop-app/browser-interception) - Configure Requestly Interceptor with popular web browsers like Chrome, Firefox, Edge, etc
* [**Android devices**](/interceptor/desktop-app/android-devices) - Intercept Traffic from your Android smartphones and tablets.
* [**Android emulator**](/interceptor/desktop-app/android-simulator-interception) - Configure Android emulators in Android Studio.
* [**iOS Devices**](/interceptor/desktop-app/ios-devices-interception) - Set up your iPhones and iPads to intercept their traffic
* [**iOS Emulator**](/interceptor/desktop-app/ios-simulator-interception) - Use Requestly Interceptor with iOS simulators in Xcode.
* [**Node.js**](/interceptor/desktop-app/nodejs) - Integrate Requestly Interceptor with Node.js applications to debug server-side network requests and responses during development or testing
* [**Terminal**](/interceptor/desktop-app/terminal) - Use Requestly Interceptor with command-line tools or scripts to intercept and manipulate HTTP requests for automation and debugging.
* [**Systemwide proxy**](/interceptor/desktop-app/desktop-app-interception) - Configure Requestly Interceptor as a systemwide proxy to capture and manipulate traffic across all applications and devices connected to your network.
# Android Devices Interception
Source: https://interceptor-docs.requestly.com/interceptor/desktop-app/android-devices
Learn how to set up Requestly Interceptor to intercept, monitor, and debug HTTP requests on your Android devices for Android app development, debugging, and testing.
***
When working with Android apps, debugging HTTP Requests can be a challenge. Requestly Interceptor provides an easy-to-use solution for everyone who needs to monitor, modify, or debug HTTP requests and responses during development or QA testing. This section outlines step-by-step instructions, guiding you on how to set up Requestly Interceptor for your Android device.
By the end of this guide, you will have a fully functional interception setup tailored to your Android development needs.
## **Step-by-Step Guide**
## Rooted Setup
If you have a rooted device the setup is straightforward -
Open **Settings > Developer Options** on your device and turn on **USB Debugging**.
Use a USB cable to connect your device to your computer and launch the **Requestly Interceptor Desktop App**.
On the Requestly Interceptor dashboard click **Connect Apps > Mobile Apps and Browser**, and Requestly Interceptor will automatically list out detected devices. Simply click **Connect** to proceed. 🎉
Once connected, a success message will appear. You can now visit [amiusing.requestly.io](http://amiusing.requestly.io) to verify your connection.
## Non Rooted Setup
If your device is not rooted, you can manually setup Requestly Interceptor by following these steps:
### Configure proxy
Tap on the Internet and click on the gear icon on the connected network name to open its settings.
* At the top right of the screen click the edit icon
* Enable "Advanced Options" if needed.
* Set the **Proxy** to "Manual."
Input the following:
* **Proxy Hostname:** Use the IP shown in the Requestly Interceptor Desktop App (e.g., `192.168.1.10`).
* **Proxy Port:** Use the port displayed in the Requestly Interceptor Desktop App (e.g., `8080`).
Apply the settings and continue with the certificate installation
### Install CA Certificate
To intercept HTTPS traffic, you also need to install Requestly Interceptor's root CA certificate on your device:
* Open Chrome in an incognito tab
* Go to [http://requestly.io/ssl](http://requestly.io/ssl) (⚠️ **Use HTTP here, not HTTPS)**
* This will download RQProxyCA.pem.cert
* Go to **Settings > Search "CA Certificate" > Install Anyway**.
* Select the downloaded certificate and install it.
After installation, confirm your setup by going to [amiusing.requestly.io](http://amiusing.requestly.io)
## **SSL Pinning \[if-required]**
From Android API level 23 (Android 6.0+), many apps enforce SSL pinning for security. To intercept HTTPS traffic, setting up SSL pinning is required.
Make sure to remove these in production builds
Add these configs to your app codebase for it to work
1. Add **res/xml/network\_security\_config.xml**
```xml theme={null}
```
1. Add to **AndroidManifest.xml**
```xml theme={null}
...
```
## **Turn off Interception**
Remember to disable the HTTP Proxy in your Settings when you stop using Requestly Interceptor, otherwise, you'll get confusing network failures in your applications! You just need to set the network proxy(part 1) the next time you want to debug with Requestly Interceptor.
Tap on the Internet and click on the gear icon on the connected network name to open its settings.
* At the top right of the screen click the edit icon
* Enable "Advanced Options" if needed.
* Set the **Proxy** to "None”
# Android Simulator Interception
Source: https://interceptor-docs.requestly.com/interceptor/desktop-app/android-simulator-interception
Learn how to set up Requestly Interceptor to intercept, monitor, and debug HTTP requests on your Android Simulator for Android app development and testing.
***
When working with Android apps, debugging HTTP Requests can be a challenge. Requestly Interceptor provides an easy-to-use solution for everyone who needs to monitor, modify, or debug HTTP requests and responses during development or QA testing. This section outlines step-by-step instructions, guiding you on how to set up Requestly Interceptor for your Android emulator.
By the end of this guide, you will have a fully functional interception setup tailored to your Android development needs.
## **Step-by-Step Guide**
### Video Guide
For a visual walkthrough, check out our YouTube video guide:
## Automatic Setup
Requestly Interceptor offers a one-click setup for Android emulators using Desktop App version **1.7.0+**. Here's how:
Ensure your emulator is up and running before proceeding
Launch the Requestly Interceptor desktop application on your computer.
## Manual Setup
If the automatic setup does not work for you, you can manually configure the proxy by following these steps:
If you have ADB installed, you can skip the proxy setup through the emulator's UI by running the following command in your Android studio terminal:
```bash theme={null}
adb shell settings put global http_proxy ":"
```
Make sure to change the: in the above command to the one mentioned in the header of the Requestly Interceptor desktop app
Otherwise, follow these steps to configure the proxy manually:
Tap on the Internet and click on the gear icon on the connected network name to open its settings.
* At the top right of the screen click the edit icon
* Enable "Advanced Options" if needed.
* Set the **Proxy** to "Manual."
* **Proxy Hostname:** Use the IP shown in the Requestly Interceptor Desktop App (e.g., `192.168.1.10`).
* **Proxy Port:** Use the port displayed in the Requestly Interceptor Desktop App (e.g., `8080`).
Apply the settings and continue with the certificate installation
## CA Certificate Installation
To intercept HTTPS traffic, you need to install Requestly Interceptor's root CA certificate on the emulator. You can do this in two ways:
**Option 1: From the Desktop:**
* Open the Requestly Interceptor Desktop App.
* Navigate to **Connect Apps > Others > Manual Setup > Save Certificate** to download the root CA certificate.
After the certificate is downloaded on your PC, Run this script in **Android Studio** to push it to the emulator using the following script:
```bash theme={null}
#!/bin/bash
subjectHash=`openssl x509 -inform PEM -subject_hash_old -in **** | head -n 1`
openssl x509 -in **** -inform PEM -outform DER -out $subjectHash.0
adb root
adb push ./$subjectHash.0 /data/misc/user/0/cacerts-added/$subjectHash.0
adb shell "su 0 chmod 644 /data/misc/user/0/cacerts-added/$subjectHash.0"
adb reboot
```
> ***Replace \ with the path to the downloaded certificate***
**Option 2: Directly on the Emulator:**
* Open Chrome in an incognito tab
* Go to [**http://requestly.io/ssl**](http://requestly.io/ssl) (⚠️ Use HTTP here, not HTTPS)
* This will download RQProxyCA.pem.cert
* Go to **Settings > Search "CA Certificate" > Install Anyway**.
* Select the downloaded certificate and install it.
After installation, confirm your setup by going to [**amiusing.requestly.io**](http://amiusing.requestly.io/)
## **SSL Pinning \[if-required]**
From Android API level 23 (Android 6.0+), many apps enforce SSL pinning for security. To intercept HTTPS traffic, setting up SSL pinning is required.
Make sure to remove these in production builds
Add these configs to your app codebase for it to work
**Step 1:** Add **res/xml/network\_security\_config.xml**
```xml theme={null}
```
**Step 2:** Add to **AndroidManifest.xml**
```xml theme={null}
...
```
## **Deactivate Proxy (After done debugging)**
Please make sure to revert the proxy after you are done testing using Requestly Interceptor
```bash theme={null}
adb shell settings put global http_proxy :0
```
# **Troubleshooting**
### **Emulator not detected?**
* Check if your emulator is running.
* Check if `adb` is installed. If not, install it from [**here**](https://developer.android.com/tools/releases/platform-tools)
* Try Restarting your emulator.
# **How does it work?**
Here's the code that makes this happen in a single click
[**https://github.com/requestly/requestly-desktop-app/blob/fb1f321a3d2431cfcd9d95d1396bcd39820a4ec9/src/renderer/actions/apps/mobile/android.js#L63-L74**](https://github.com/requestly/requestly-desktop-app/blob/fb1f321a3d2431cfcd9d95d1396bcd39820a4ec9/src/renderer/actions/apps/mobile/android.js#L63-L74)
1. Searches for online ADB devices
2. On `Connect`
1. Root the device (To install Requestly Interceptor CA)
2. Inject Requestly Interceptor CA (if not already)
3. Setup Proxy on Emulator
4. Restart the Emulator (Only first time)
3. On `Disconnect` - Removes the Proxy
# Browser Interception
Source: https://interceptor-docs.requestly.com/interceptor/desktop-app/browser-interception
Requestly Interceptor desktop app allows you to connect multiple browsers, making it easy to configure and switch between them for network interception.
To connect browser instance, open the **Connect Panel**, follow these steps:
Navigate to the **Network Traffic** tab located on the right sidebar.
Click on any of the `Connect Apps` buttons, as shown below:
This will open the **Connect Panel**, displaying all supported browsers on your system, along with other sources that Requestly Interceptor supports.
Select your preferred browser from the Connect Panel and click **Launch/Open**. This will start a new browser instance configured with the Requestly Interceptor proxy.
1. For Chromium-based browsers, Requestly Interceptor applies the `--proxy-server` flag, configuring the browser to route all network traffic through the Requestly Interceptor proxy server
2. Then requestly automatically installs CA certificate to your system’s certificate store.
The newly launched browser instance will automatically open [amiusing.requestly.io](https://amiusing.requestly.io/). A success message on this page confirms that the browser is using Requestly Interceptor’s proxy.
Return to the Requestly Interceptor dashboard to review all captured network traffic in the Network table.
## Supported Browsers & Profiles
The **Connect Panel** shows a list of browsers that Requestly Interceptor supports. You can select from various profiles for browsers such as Google Chrome, Firefox, and Safari. Here are the details of each browser and its profile options:
* **Google Chrome (New Profile)**:
Launch a new browser profile without any pre-configured settings, logins, or extensions. This is ideal for testing requests in a clean environment.
* **Google Chrome (Existing Profile)**:
Use an existing Chrome profile to connect, keeping all your extensions, settings, and history intact.
* **Firefox**:
Connect to Firefox for testing your network requests on this browser. it will launch a new profile with a clean environment.
* **Arc**:
Arc is another modern browser supported by Requestly Interceptor. You can create a new profile or use an existing one.
* **Safari**:
Connect to the Safari browser, clicking the connect button will open a new Safari window.
When you launch Safari from Requestly Interceptor, it sets a system-wide proxy due to technical constraints. Make sure to turn it off after done debugging
For other browsers, find the proxy IP and port at the top of Requestly Interceptor’s dashboard and refer to your browser's documentation to configure proxy settings.
## **Connect existing browser profile**
You can connect your existing browser profile to the desktop app using the [**Requestly Interceptor extension**](https://requestly.com/downloads/)**.**
Available on desktop app version >=1.7.4
## **Steps to connect using browser extension**
1. Launch the desktop app
2. Open the Requestly Interceptor extension popup in the browser profile you want to connect.
**This button is only visible when the desktop app is open.**
3. You should see a connect button in the popup to connect with the desktop app.
4. Click on the button and the desktop app starts intercepting the traffic.
With this method, you can easily link your current browser profile to the desktop app without needing to relaunch or lose your browsing session
## Custom Browser Launch Options
Requestly Interceptor offers **custom browser launch options** for certain browsers, specifically Chromium-based ones. These options allow you to tweak the behavior of the browser during interception.
Use the buttons next to the browser selection to customize the launch options. Here's a quick rundown of the **preset configurations**:
**Without Safety Checks** Disables security restrictions, allowing insecure content to run and third-party modules to load. Flags used:
* `--allow-running-insecure-content` Allows the browser to load content from websites that are not served over HTTPS.
* `--allow-insecure-localhost` Allows insecure content to be loaded from `localhost`
* `--allow-third-party-modules` Allows third-party modules (which could include extensions or custom scripts) to run even if they are not from trusted sources
**Without CORS** The `--disable-web-security` flag disables CORS (Cross-Origin Resource Sharing) restrictions in the browser, allowing requests to be made across different domains without security checks, to learn more on cors check out our blogpost here.
**With Custom Arguments**
Launch the browser with custom flags (only supported for Chromium-based browsers). Here are some interesting flags for launching Chromium-based browsers with custom arguments:
`--incognito`: Launches Chromium in Incognito mode by default.
`--window-size`: Sets the initial window size. Provided as a string in the format "800,600".
`--user-agent` : A string used to override the default user agent with a custom one.
A full list of available arguments can be found **here**.
# System Wide Proxy
Source: https://interceptor-docs.requestly.com/interceptor/desktop-app/desktop-app-interception
Learn how to set up and manage a system-wide proxy with Requestly Interceptor to intercept and debug network requests across all applications.
***
Setting up a system-wide proxy allows you to intercept and debug network requests from all applications on your computer, not just your browser. This is particularly useful in situations where an application-level proxy setup is not available.
This feature is only available in the **Requestly Interceptor Desktop App**. Ensure you are using the desktop version to proceed with these steps.
## Setting Up System-Wide Proxy
Open the Requestly Interceptor desktop app and click the **Connect App** button at the top to view the sources you can intercept.
From the displayed sources, select **Enable Requestly Interceptor system-wide** to enable traffic interception across all applications on your device.
The first time you select this option, you’ll be prompted to enter your system password. This step allows Requestly Interceptor to add its CA certificate to your system, making it possible to modify HTTPS requests.
Once the system-wide proxy is enabled, network traffic will start appearing in the network table. You can click on any request to view request and response details, setup rules, etc.
## Turn Off System-Wide Proxy
To disable the system-wide proxy, go to the **Connect App** section in the Requestly Interceptor Desktop App and click on the **Disconnect** option to turn it off. This will stop intercepting traffic across your system.
### Filtering by App and Domain
Requestly Interceptor makes it easy to organize and focus on specific network traffic:
Requestly Interceptor provides two dropdowns in the **Network Inspector's** left sidebar for easy filtering:
* **Apps Dropdown**:
This dropdown lists all the applications on your system that are making network requests. Clicking on an app filters the traffic in the network table to show only the requests originating from that application.
* **Domains Dropdown**:
This dropdown lists all the domains accessed by the applications on your system. Clicking on a domain filters the traffic in the network table to display only the requests made to or from that domain.
These filtering options help you focus on specific network traffic. For example, you can isolate requests from a single application or focus on traffic for a specific API or website
# iOS Devices Interception
Source: https://interceptor-docs.requestly.com/interceptor/desktop-app/ios-devices-interception
Learn how to set up Requestly Interceptor to intercept, monitor, and debug HTTP requests on your iOS Apps for iOS app development, debugging, and testing.
***
When working with iOS apps, debugging HTTP requests can be challenging. Requestly Interceptor offers an easy-to-use solution for monitoring, modifying, and debugging HTTP requests and responses during development or QA testing. Once you're familiar with the [HTTP Interceptor and network table](/interceptor/overview), you can follow step-by-step instructions to set up Requestly Interceptor for intercepting network traffic on your iOS devices, ensuring a fully functional interception setup for your iOS app development needs.
iOS device interception is only supported on the Desktop App.
## **Setup iOS Devices for Interception**
Setting up HTTP interception on physical iOS devices requires configuring a proxy and CA Certificate to intercept network traffic.
### Part 1: Configure Proxy
Connect your iOS Device(iPhone or iPad) on the same network as your computer having a Desktop App.
These steps are available on the Desktop app as well.\
\
To open, click on `Connect App` button, and switch to `Mobile apps & browsers` tab.\
Click on `Setup Instructions` next to iOS.
On your iOS device, navigate to `Settings` → `Wi-Fi` → `Select current Wi-Fi` → `Configure Proxy`
Set the proxy settings to `Manual`. Then, enter the IP address of the computer and the proxy port. You can find these on the top banner of the Requestly Interceptor desktop app.
To ensure that the proxy has been set, visit [**http://amiusing.requestly.io**](http://amiusing.requestly.io)**(remember to use HTTP, not HTTPS)** on Safari Browser of your mobile. If the rendered page shows success, the proxy is now correctly configured. You should be able to see some traffic on the Desktop app, but the body of the request/response is encrypted. To decrypt that we will have to install the CA Certificate in upcoming steps.
### Part 2: Install CA Certificate
Now open Safari on your IOS device and go to [**http://requestly.io/ssl**](http://requestly.io/ssl)**(remember to use HTTP, not HTTPS)**. This should download a custom profile on your device which contains the Requestly Interceptor CA certificate.
Now to install the downloaded custom profile go to `Settings`. You should see a new option at the top that says Profile Downloaded. Select that to install the profile. Click on Install.
Finally, you need to enable trust for CA certificates that were installed along with this custom profile. Go to `Settings` → `General` → `About` → `Certificate Trust Settings`. You should see a certificate under the name RQProxyCA. Enable the trust for Requestly Interceptor's certificate authority for intercepting HTTPS traffic.
Once everything is setup properly you should be able to see decrypted traffic on Desktop App. Clear the log from the desktop app and check the request/response body of a few requests, you should be able to see readable data.
## **Turn off Interception**
Remember to disable the HTTP Proxy in your Settings when you stop using Requestly Interceptor, otherwise, you'll get confusing network failures in your applications! You just need to set the network proxy(part 1) the next time you want to debug with Requestly Interceptor.
1. Navigate to `Settings` → `Wi-Fi` → `Select current Wi-Fi` → `Configure Proxy`
2. Set the proxy settings to `Off`
# iOS Simulator Interception
Source: https://interceptor-docs.requestly.com/interceptor/desktop-app/ios-simulator-interception
Learn how to set up Requestly Interceptor to intercept, monitor, and debug HTTP requests on your iOS Simulator for iOS app development and testing.
***
When working with iOS apps, debugging HTTP requests can be challenging. Requestly Interceptor offers an easy-to-use solution for monitoring, modifying, and debugging HTTP requests and responses during development or QA testing. Once you're familiar with the HTTP Interceptor and network table, you can follow step-by-step instructions to set up Requestly Interceptor for intercepting network traffic on your iOS Simulator, ensuring a fully functional interception setup for your iOS app development needs.
iOS Simulator interception is only supported on the Desktop App.
## **Setup iOS Simulator for Interception**
The **iOS Simulator** is a virtual device that runs on a Mac desktop or laptop, and its proxy setup for HTTP interception is similar to that of a physical device. Since the simulator runs locally on your Mac, Requestly Interceptor offers an added advantage by enabling a seamless, **one-click setup** for interception.
### One-click Simulator Setup for Interception
**Step 1**: Launch the iOS Simulator for your app.
Make sure the simulator is running before proceeding.
**Step 2**: In Requestly Interceptor Desktop App, open **Connect Apps** Panel, switch to **Mobile apps & browsers** tab, and click **Refresh Device**. This will display all currently running simulators.
**Step 3**: Verify that your simulator appears in the list.
**Step 4**: Click **Connect All** button next to your simulator. This action will set up the proxy configuration and automatically trust the root certificate on the simulator.
**Step 5**: Once connected, you will see all network traffic being captured.
This will enable system-wide proxy because iOS simulators use systems NIC directly instead of creating a virtual NIC. You will see lots of traffic from your computer and iOS, you can filter the traffic by App name.
### Troubleshooting
#### Simulator Not Listed in Requestly Interceptor?
If you do not see your simulator listed after refreshing, follow these steps:
```bash theme={null}
xcrun simctl
```
If this command returns an error, it indicates an issue with your Xcode command-line tools.
```bash theme={null}
sudo xcode-select -s /Applications/Xcode.app
```
This command ensures that the correct Xcode installation is selected.
# Network Table
Source: https://interceptor-docs.requestly.com/interceptor/desktop-app/network-table
The **Network Table** is the heart of Requestly Interceptor’s Desktop App; here you can monitor, inspect, and manage all intercepted network traffic. It’s packed with powerful features to help you debug with ease. Here's a quick overview of its key components:
1. **Traffic Table -** Displays all intercepted requests and responses with key details like URL, status, and time.
2. **Export HAR button** **-** Export captured network traffic as a HAR file for analysis or sharing.
3. **Save Session Button** **-** Save the current network session for future debugging or comparison.
4. **Request / Response Details -** Show detailed headers, payloads, and cookies for selected requests or responses.
5. **Search and Filter options -** Quickly find traffic entries using search keywords or advanced filters.
6. **Clear Logs or Pause Button -** Clears logs or pauses traffic capture to reduce noise and focus.
7. **App and Domains Filter -** Filters traffic by specific apps or domains for focused analysis.
## **Filtering Traffic**
Use the filter option to find a set of particular requests from hundreds of intercepted requests. There are 4 types of filters available as follows:
* **URL**: Filter requests by using a string search on the URL of the request.
* **Method**: Filter by HTTP methods such as: GET, POST, PUT, PATCH, or DELETE.
* **Status Code**: Narrow down by response status codes, including 1XX (Informational), 2XX (Success), 3XX (Redirection), 4XX (Client Errors), and 5XX (Server Errors).
* **Resource Type**: Focus on specific resource types like HTML, JSON, JavaScript, CSS, Images, Media (Audio and Video), FormData, or Fonts.
## Network Modification
One of Requestly Interceptor’s most powerful capabilities is **network modification**, allowing you to dynamically alter requests and responses in real time. This feature helps in debugging, testing, and even bypassing certain network constraints. Here’s how you can modify network traffic:
Right-click on any network request in the Network Traffic table.
Choose the rule you want to create from the available options.
Fill in the necessary details for modification in the Rule Editor Modal
Click on the **Create Rule** button at the top-right corner of the Rule Editor Modal
### Testing Modification
Now, when the same request is triggered again, the request will be highlighted. This indicates that the Requestly Interceptor Rule is applied to the request.
These modification tools provide developers with greater control over their network traffic, enabling deeper debugging and customization without needing backend changes.
# Node.js
Source: https://interceptor-docs.requestly.com/interceptor/desktop-app/nodejs
Learn How to Set Up Requestly Interceptor Proxy in Your Node.js Application
## **Steps**
Go to the **Requestly Interceptor desktop** **app** and click on the **Connect apps** button. A popup modal will appear.
In the popup modal, navigate to the **Terminal processes** section. Click on **Setup instruction** for Terminal.
You will see a command displayed in the setup instructions. Copy the command. It will look something like this:
```plaintext theme={null}
<(curl -sS localhost:7040/tpsetup)
```
> ***Note: This command might be different depending upon port availability. Checkout in Connected Apps > Terminal***
Open the terminal where you will start your **Node.js server** and paste the copied command. Press **Enter** to execute it.
If the command runs successfully, you should see a confirmation message in your terminal indicating that **interception is enabled**.
> ***https requests in axios might not show up properly in Network Traffic tab due to the way axios handles HTTPS requests. But the actual request will work properly in your code as expected.***
>
> ***Checkout*** [***Github Issue***](https://github.com/requestly/requestly/issues/301) ***for more explanation and quick hack on how to apply rules on these requests***
## **Testing Proxy**
1. Go to `Network Traffic` tab in Requestly Interceptor Desktop App.
2) Now Make a curl request to [**https://amiusing.requestly.io/**](https://amiusing.requestly.io/) using your terminal and look for that request in the **Network Traffic** tab.
# Saving Logs to local file
Source: https://interceptor-docs.requestly.com/interceptor/desktop-app/saving-logs-to-local-file
For external scripts to work on top of the intercepted logs you can enable savings logs to a local file.
Navigate to settings from the icon on the top right and under `Desktop Settings` there is a section for `Session Log Storage`
Note: The logs do get cleared whenever app restarts
This is done to avoid the log file from getting unnecessarily large which has shown to cause performance issues
The mentions the path of the file where the log is stored.
This is a `.jsonl` file where each line is an intercepted request stored as a `har` with one entry.
The request is added to the file only if the url matches any of the substrings that you add as matching strings
# Intercept Traffic from your terminal
Source: https://interceptor-docs.requestly.com/interceptor/desktop-app/terminal
Learn how to set up the Requestly Interceptor proxy in the terminal to intercept and modify terminal requests effortlessly.
## **Steps**
Go to the **Requestly Interceptor desktop** **app** and click on the **Connect apps** button. A popup modal will appear.
In the popup modal, navigate to the **Terminal processes** section. Click on **Setup instruction** for Terminal.
You will see a command displayed in the setup instructions. Copy the command. It will look something like this:
```plaintext theme={null}
<(curl -sS localhost:7040/tpsetup)
```
> ***Note: This command might be different depending upon port availability. Checkout in Connected Apps > Terminal***
Open the terminal where you will start your **Node.js server** and paste the copied command. Press **Enter** to execute it.
If the command runs successfully, you should see a confirmation message in your terminal indicating that **interception is enabled**.
## **Testing Proxy**
1. Go to `Network Traffic` tab in Requestly Interceptor Desktop App.
2) Now Make a curl request to [**https://amiusing.requestly.io/**](https://amiusing.requestly.io/) using your terminal and look for that request in the **Network Traffic** tab.
```plaintext theme={null}
curl https://amiusing.requestly.io/
```
3. You should see the Request in the `Network Traffic` Table.
# Overview
Source: https://interceptor-docs.requestly.com/interceptor/overview
Learn when to use HTTP Interceptor, choose the right interception setup, and debug traffic across browsers, devices, and runtimes.
HTTP Interceptor helps you inspect and debug real network traffic. Use it when you need to see what your browser, app, device, or runtime is actually sending and receiving.
## When To Use HTTP Interceptor
Use HTTP Interceptor when you want to:
* inspect requests and responses in real time
* debug browser, mobile, emulator, terminal, or Node.js traffic
* verify whether an issue is in the client, proxy, or backend
* capture traffic for sessions, HAR analysis, or later mocking
If you already know exactly how you want to change traffic, go to [HTTP Rules](/http-rules/overview).
## Choose Your Interception Setup
Best for browser-only workflows and the fastest setup.
Best for mobile apps, emulators, localhost, terminal tools, Node.js, and system-wide traffic.
## First Success Path
Use the Browser Extension for browser-based traffic. Use the Desktop App when you need proxy-based interception outside the browser.
Follow one setup path and make sure the browser, device, or runtime is correctly connected to Requestly Interceptor.
Open the [network table](/interceptor/desktop-app/network-table) or browser interception view and verify requests appear before moving on to rules or mocks.
## Explore By Runtime
Connect Chrome, Firefox, Edge, and similar browsers through the Desktop App.
Intercept traffic from Android phones and tablets.
Capture traffic from Android Studio emulators.
Set up iPhones, iPads, and iOS simulators.
Debug server-side requests from Node.js applications.
Inspect cURL, scripts, and other command-line network activity.
## After Traffic Starts Flowing
Modify intercepted traffic once you know what needs to change.
Save traffic and debugging context for sharing, replaying, or mock creation.
Analyze previously captured network data inside Requestly Interceptor.
Use the troubleshooting path for certificate, localhost, proxy, or device issues.
# Create
Source: https://interceptor-docs.requestly.com/mock-server/create
Learn how to create and organize files and endpoints in File Server.
File Server lets you upload JSON, CSS, and JS files and use them in your application to test features, serve APIs, or override assets without touching production code.
Upload a JSON File and use it as an API to simulate server responses. Define request and response behaviours to test without a backend.
Upload CSS/JS files and use them in your application to test UI changes, inject features, or override production assets
Group related files into collections to keep File Server organized. The folder structure you create inside a collection is reflected in the file URLs.
# Create JSON Files
Source: https://interceptor-docs.requestly.com/mock-server/create/create-mock-api
You can upload a JSON file to Requestly Interceptor’s File Server and use it as a API endpoint in your application by creating a Redirect Rule, which is perfect for testing and development scenarios. Here are the steps to set it up:
From the Requestly Interceptor dashboard, click on "Files" in the left menu bar.
This allows you to start creating a new JSON or import an existing JSON file.
Provide a descriptive name for the file and Configure the following options on the creation screen:
* **Method**: Select the HTTP method to be used (e.g., GET, POST, etc.).
* **Status**: Specify the HTTP response status code (e.g., 200, 404, 500).
* **Content Type**: Define the content type of the response (e.g., application/json).
* **Latency**: Optionally, add a delay (in milliseconds) to simulate network latency.
* **Endpoint**: Define the unique path or endpoint for the File.
* **Response Body**: Provide the body of the response in JSON or plain text.
* **Response Headers** (optional): Add custom headers to the response as needed.
* **Password Protection**: In the "More" dropdown, you can set a password for your JSON file. If a password is set, users must include it as a query parameter (e.g., `rq_password=`) to access the file’s contents.
Once created, you can copy the generated URL using the “Copy URL” button.
Your JSON file is now ready! Copy the generated URL to see it in action. This endpoint can be utilized in multiple ways:
* Integrate the endpoint into your application to replace live API calls during testing.
* Use tools like Postman or cURL to manually test and validate the file responses.
# Create JS/CSS Files
Source: https://interceptor-docs.requestly.com/mock-server/create/create-new-mock-file
You can upload and use JavaScript and CSS files on Requestly Interceptor’s File Server. This lets developers host JS or CSS files for testing and development purposes. Here are the steps to create a JS/CSS File:
From the Requestly Interceptor dashboard, click on "Files" then “JS/CSS Files” in the left menu bar.
From the popup, select the type of file you want to host (CSS or JS)
Enter the following details:
* **Name**: Provide a descriptive name for the file.
* **Data**: Input the file content directly or upload the file.
* **Endpoint**: Define a unique endpoint for accessing the file.
Once created, you can copy the generated URL using “Copy URL” button to access the hosted file and see it in action.
# Use File Collection
Source: https://interceptor-docs.requestly.com/mock-server/create/mock-collection
Mock collections provide a structured way to manage your mocks. Each collection can optionally include a static “path” that is automatically prepended to the mock endpoints within that collection. This feature is particularly useful for versioning your mocks, ensuring consistency and clarity across different versions of your API.
### Key benefits
1. **Efficient Organization**:
* Group related mocks together, making it easier to manage and locate them.
2) **Better Versioning**:
* Utilize the static "path" feature to prepend a version identifier or other relevant prefixes to your mock endpoints.
* Simplify the process of updating and managing multiple versions of your API.
### Example
Consider a collection for API version 1.0:
* Collection path: `/api/v1`
- Mock Endpoints:
* `/users`
* `/products`
With the collection path, the actual mock endpoints become:
* `/api/v1/users`
- `/api/v1/products`
This approach ensures that all endpoints within the collection are easily versioned, improving maintainability and clarity.
**Creating a New Collection:**
From the Requestly Interceptor dashboard, click on "Mock" in the left menu bar.
On the top right side of the table, click on new collection
* **Name**: Give the collection a name.
* **Collection Path**: A path which gets prepended to all the mocks inside this collection. For example, if the collection path is "/api/v1", then all the child mocks’ endpoints will start with this path.
* **Description**: Provide a brief description of the collection.
**Moving Mocks into a Collection:**
Once the collection is created, you can move mocks into it:
# Import and Export Files
Source: https://interceptor-docs.requestly.com/mock-server/import-and-export-mocks
Requestly Interceptor makes it easy to import and export File Server files as JSON. This helps you share, back up, or reuse mocks across different projects with just a few clicks.
### Steps to Import Files:
Go to [File Server](https://app.requestly.io/mock-server/apis). Under the JSON Files section, click on the Import button.
Select the JSON file containing the files you want to import. Review the list, then click **Import** to add them to File Server.
### **Steps to Export** Files
Use the checkboxes to select the files you want to export from File Server.
In the bottom popup, click on export
Requestly Interceptor will prepare your selected files for export. Click **Export Files** to download the JSON file.
# Overview
Source: https://interceptor-docs.requestly.com/mock-server/overview
Learn when to use File Server, how it differs from in-place traffic modification, and how to create your first hosted mock.
Requestly Interceptor **File Server** lets you host reusable mock endpoints and static assets for testing, demos, and development workflows.
You may still see references to "File Server" in some parts of the product. This feature is called **File Server**.
## When To Use File Server
Use File Server when you want to:
* create hosted mock APIs for frontend or QA work
* serve JSON, JavaScript, CSS, images, or other test assets over a public URL
* share reusable mocks with teammates
* combine hosted mocks with [HTTP Rules](/http-rules/overview) to redirect live requests to mock endpoints
If you only need to change traffic inside your current browser or app session, [HTTP Rules](/http-rules/overview) may be faster. If you need a quick local response override, [API Mocking](/api-mocking/api-mocking) may be a better fit.
## First Success Path
Start with [Create Mock API](/mock-server/create/create-mock-api) to define an endpoint and response.
Verify the response using [Test Mock APIs](/mock-server/test) or your preferred client.
Use the mock directly, or pair it with [Redirect Rule](/http-rules/rule-types/redirect-rule) to switch traffic to your hosted mock.
## Explore By Workflow
Build and publish your first mock endpoint.
Validate responses before connecting apps or teammates.
Add dynamic values and richer mock behavior.
Move mocks between workflows and share them more easily.
Start with local or cloud-based quick mocks when you do not need a full hosted mock server.
Route live requests to your mock endpoint without changing application code.
# Pre-Configured Files
Source: https://interceptor-docs.requestly.com/mock-server/pre-configured-mocks
* 404: [https://mocks.requestly.dev/status/404](https://mocks.requestly.dev/status/404)
- 200: [https://mocks.requestly.dev/status/200](https://mocks.requestly.dev/status/200)
* 500: [https://mocks.requestly.dev/status/500](https://mocks.requestly.dev/status/500)
More Predefined Mocks are coming soon..
# Templating in File server
Source: https://interceptor-docs.requestly.com/mock-server/templating-in-mocks
Our methods support handlebars-like templating (`{{}}` )along with the following special methods to make your responses dynamic
1. `urlParam`
You can define parameters inside the mock endpoint using a colon (`:`).
For example - the endpoint `/book/:id` defines the `id` parameter that can be used inside the body of your mocks as `{{urlParam 'id'}}`
2. `header`
The value of any of the request headers can be dynamically rendered into your response using this method.
For example - the string `{{header 'content-type'}}` renders the value of the content-type header
3. `method` : You can add the request method to your mock's response body by including `{{method}}` in your mock response
4. `statusCode` : Renders the original status code inside the template
Let us know if you have ideas for other templating methods that you might need.
# Test File Server
Source: https://interceptor-docs.requestly.com/mock-server/test
After saving a file or mock in File Server, you can use the built-in **Test** action to verify that the response matches your expectations.
Open the JSON file from the list of files available in the files Dashboard.
In the top header of the JSON file, click the Test button to initiate the testing process.
A dialog box will open with the endpoint URL field and the request method already pre-populated in the user interface for your convenience.
Click the **Send** button to trigger the request and view the response. The response body and headers returned from the file will be displayed in the interface.
This confirms that the JSON is served as expected and can now be integrated into your application for further use.
# Create A New Group
Source: https://interceptor-docs.requestly.com/public-apis/create-group
Learn how to create groups in Requestly Interceptor's API for better rule organization and management
***
This endpoint allows you to create a new group in your Requestly Interceptor account. Groups help in organizing and managing rules efficiently.
For a live view and to test this API interactively, visit the API Playground.
***
### Endpoint
* **Method**: POST
* **URL**: `https://api2.requestly.io/v1/groups`
***
### Body Parameters
| **Parameter** | **Type** | **Description** | **Required** | **Default Value** |
| ------------- | -------- | ------------------------------------------------------- | ------------ | ----------------- |
| `name` | String | The name of the group to be created. | Yes | - |
| `status` | String | The status of the group. Options: `Active`, `Inactive`. | No | `Active` |
| `isFavourite` | Boolean | Pins the group (true or false). | No | `false` |
***
### cURL Request
```bash theme={null}
curl --request POST \
--url https://api2.requestly.io/v1/groups \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--header 'x-api-key: your_api_key' \
--data '{
"name": "Group",
"status": "Active",
"isFavourite": false
}'
```
***
### Sample Response
```json theme={null}
{
"success": true,
"data": {
"id": "Group_qrszh",
"creationDate": 1736059835086,
"modificationDate": 1736059835086,
"createdBy": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"lastModifiedBy": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"name": "Group",
"objectType": "group",
"status": "Inactive",
"isFavourite": false,
"currentOwnerId": "IUAGkRiEx6XI0B6qCc82qbwroKX2"
}
}
```
***
### Response Codes
| **Status Code** | **Description** |
| --------------- | --------------------------- |
| **200** | Group created successfully. |
| **400** | Invalid group payload. |
| **401** | Unauthorized action. |
| **500** | Server error. |
# Create Rule
Source: https://interceptor-docs.requestly.com/public-apis/create-rule
Learn how to create a rule in Requestly Interceptor's API for URL redirects, modifications, or other rule types.
***
This endpoint allows you to create various types of rules in Requestly Interceptor, such as Redirect, Cancel, Replace, Headers, User-Agent, Query Param, Modify Request, Modify Response, and Delay. Each rule has a specific structure and parameters.
## Endpoint
* **Method**: POST
* **URL**: `https://api2.requestly.io/v1/rules`
***
## Request Structure
### Body Parameters
| Name | Type | Required | Default | Description |
| --------------- | ------------------ | -------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **name** | `string` | Yes | | Name of the rule. |
| **description** | `string` | No | | Description of the rule. |
| **objectType** | `string` | Yes | `rule` | Type of the object. For this endpoint, it is always `rule`. |
| **ruleType** | `string` | Yes | | Type of the rule. Possible values are: `Redirect`, `Cancel`, `Replace`, `Headers`, `UserAgent`, `QueryParam`, `Request`, `Response`, `Delay`. |
| **status** | `string` | No | `Active` | Status of the rule, either `Active` or `Inactive`. |
| **pairs** | `array of objects` | Yes | | List of key-value pair objects that define the specific conditions and actions for the rule. The structure and details of each pair vary based on the rule type. |
| **groupId** | `string` | No | | The ID of the group the rule belongs to. If omitted, the rule is ungrouped. |
***
## cURL Request
```bash theme={null}
curl --request POST \
--url https://api2.requestly.io/v1/rules \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--header 'x-api-key: your_api_key' \
--data '
{
"objectType": "rule",
"ruleType": "Redirect",
"status": "Inactive",
"pairs": [
{
"destinationType": "url",
"source": {
"value": "https://www.google.com/",
"operator": "Equals",
"key": "Url"
},
"destination": "https://www.bing.com/"
}
],
"name": "Redirect to Bing"
}
'
```
## Response
```json theme={null}
{
"success": true,
"data": {
"id": "Redirect_wi3uj",
"creationDate": 1736060959798,
"modificationDate": 1736060959798,
"createdBy": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"lastModifiedBy": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"name": "Redirect to Bing",
"description": "",
"ruleType": "Redirect",
"objectType": "rule",
"pairs": [
{
"destinationType": "url",
"source": {
"value": "https://www.google.com/",
"operator": "Equals",
"key": "Url"
},
"destination": "https://www.bing.com/",
"id": "jnc6s"
}
],
"groupId": "",
"status": "Inactive",
"isSample": false,
"isFavourite": false,
"schemaVersion": "3.0.0",
"extensionRules": [
{
"action": {
"type": "redirect",
"redirect": {
"url": "https://www.bing.com/"
}
},
"condition": {
"urlFilter": "|https://www.google.com/|",
"isUrlFilterCaseSensitive": true,
"excludedInitiatorDomains": [
"requestly.io"
],
"excludedRequestDomains": [
"requestly.io"
]
}
}
],
"currentOwnerId": "IUAGkRiEx6XI0B6qCc82qbwroKX2"
}
}
```
***
## Rule Type Details
Each rule type has a unique structure for its **pairs** of objects. The schemas for each rule type are detailed below:
### Common Source Schema
The source object is consistent across all rule types. It has the following structure:
| Property | Type | Required | Description |
| ------------ | -------- | -------- | -------------------------------------------------------------------------------- |
| **key** | `string` | Yes | The key for the source (e.g., `url`, `host`, `path`). |
| **operator** | `string` | Yes | The operator for matching (`Equals`, `Contains`, `Matches`, `Wildcard_Matches`). |
| **value** | `string` | Yes | The value to match against. |
| **filters** | `array` | No | Optional filters for more accurate targeting. |
***
### Redirect Rule
* **ruleType**: `Redirect`
* **pairs** schema:
| Property | Type | Required | Description |
| ------------------- | -------- | -------- | ------------------------------------------------------------------------------ |
| **source** | `object` | Yes | The source object for matching (see common source schema). |
| **destinationType** | `string` | Yes | Type of the destination (`u`below`rl`, `map_local`, or `mock_or_file_picker`). |
| **destination** | `string` | Yes | The destination URL value. |
***
### Cancel Rule
* **ruleType**: `Cancel`
* **pairs** schema:
| Property | Type | Required | Description |
| ---------- | -------- | -------- | ------------------------------- |
| **source** | `object` | Yes | The source object for matching. |
***
### Replace Rule
* **ruleType**: `Replace`
* **pairs** schema:
| Property | Type | Required | Description |
| ---------- | -------- | -------- | ------------------------------- |
| **source** | `object` | Yes | The source object for matching. |
| **from** | `string` | Yes | The target string to replace. |
| **to** | `string` | Yes | The replacement value. |
***
### Headers Rule
* **ruleType**: `Headers`
* **pairs** schema:
| Property | Type | Required | Description |
| ----------------- | -------- | -------- | ----------------------------------------- |
| **source** | `object` | Yes | The source object for matching. |
| **modifications** | `array` | Yes | List of header modifications (see below). |
**Header Modification Object:**
| Property | Type | Required | Description |
| ---------- | -------- | -------- | ------------------------------------------------------------------ |
| **header** | `string` | Yes | The name of the header to modify. |
| **type** | `string` | Yes | Modification type (`Add`, `Remove`, or `Modify`). |
| **value** | `string` | No | The value to set for the header (required for `Add` and `Modify`). |
***
### User-Agent Rule
* **ruleType**: `UserAgent`
* **pairs** schema:
| Property | Type | Required | Description |
| ------------- | -------- | -------- | ------------------------------- |
| **source** | `object` | Yes | The source object for matching. |
| **userAgent** | `string` | Yes | The User-Agent string to set. |
***
### Query Param Rule
* **ruleType**: `QueryParam`
* **pairs** schema:
| Property | Type | Required | Description |
| ----------------- | -------- | -------- | --------------------------------------------------- |
| **source** | `object` | Yes | The source object for matching. |
| **modifications** | `array` | Yes | Array of query parameter modifications (see below). |
**Query Param Modification Object:**
| Property | Type | Required | Description |
| --------- | -------- | -------- | ----------------------------------------------------- |
| **param** | `string` | Yes | The name of the query parameter to modify. |
| **type** | `string` | Yes | Modification type (`Add`, `Remove`, or `Remove All`). |
| **value** | `string` | No | The value to set (required for `Add` and `Modify`). |
***
### Modify Request Rule
* **ruleType**: `Request`
* **pairs** schema:
| Property | Type | Required | Description |
| --------- | -------- | -------- | -------------------------------------------------- |
| **type** | `string` | Yes | Type of request modification (`code` or `static`). |
| **value** | `string` | Yes | The request value or code. |
***
### Modify Response Rule
* **ruleType**: `Response`
* **pairs** schema:
| Property | Type | Required | Description |
| ----------------------- | --------- | -------- | ------------------------------------------------------------------ |
| **type** | `string` | Yes | Type of response modification (`code` or `static`). |
| **value** | `string` | Yes | The response value or status code. |
| **serveWithoutRequest** | `boolean` | No | Whether to serve the response directly from Requestly Interceptor. |
***
### Delay Rule
* **ruleType**: `Delay`
* **pairs** schema:
| Property | Type | Required | Description |
| ---------- | -------- | -------- | ------------------------------- |
| **source** | `object` | Yes | The source object for matching. |
| **delay** | `number` | Yes | Delay value in milliseconds. |
***
## Responses
| Status Code | Description |
| ----------- | ----------------------------- |
| **200** | Rule created successfully. |
| **400** | Invalid rule or payload. |
| **401** | Unauthorized action. |
| **404** | Rule or group not found. |
| **405** | Rule type update not allowed. |
| **429** | Too many requests. |
# Delete Group
Source: https://interceptor-docs.requestly.com/public-apis/delete-group
Learn how to delete specific groups in Requestly Interceptor's API with steps and example responses.
***
This endpoint allows you to delete a specific group using its unique ID.
Deleting a group does not delete the rules within it. Instead, the rules are moved out of the group and remain intact in your account
For a live view and to test this API interactively, visit the [API Playground](https://requestly.readme.io/reference/delete_groups-id).
***
### Endpoint
* **Method**: DELETE
* **URL**: `https://api2.requestly.io/v1/groups/{id}`
***
### Path Parameters
| Parameter | Type | Description | Required |
| --------- | ------ | --------------------------------------------- | -------- |
| id | String | The unique identifier of the group to delete. | Yes |
***
### **cURL** Request
```bash theme={null}
curl --request DELETE \
--url https://api2.requestly.io/v1/groups/Group_qrszh \
--header 'accept: application/json' \
--header 'x-api-key: your_api_key'
```
***
### Sample Response
```json theme={null}
{
"success": true,
"message": "Group deleted successfully"
}
```
***
### Response Codes
| **Status Code** | **Description** |
| --------------- | ----------------------------------- |
| **200** | Group deleted successfully. |
| **400** | The provided group ID is invalid. |
| **401** | Unauthorized action. |
| **404** | The specified group does not exist. |
| **500** | An error occurred on the server. |
# Delete Rule
Source: https://interceptor-docs.requestly.com/public-apis/delete-rule
Learn how to delete specific rules in Requestly Interceptor's API with required parameters and response examples
***
This endpoint allows you to delete a specific rule from your Requestly Interceptor account using its unique `ruleId`.\
Use this API call to permanently remove a rule that is no longer required.
For a live view and to test this API interactively, visit the [API Playground](https://requestly.readme.io/reference/delete_rules-ruleid).
***
### Endpoint
* **Method**: DELETE
* **URL**: `https://api2.requestly.io/v1/rules/{ruleId}`
***
### Path Parameters
| **Parameter** | **Type** | **Description** | **Required** |
| ------------- | -------- | ---------------------------------------- | ------------ |
| `ruleId` | String | The unique ID of the rule to be deleted. | Yes |
***
### cURL Example
```bash theme={null}
curl --request DELETE \
--url https://api2.requestly.io/v1/rules/Redirect_a9qau \
--header 'accept: application/json' \
--header 'x-api-key: your_api_key'
```
***
### Sample Response
```json theme={null}
{
"success": true,
"message": "Rule deleted successfully"
}
```
***
### Response Codes
| **Status Code** | **Description** |
| --------------- | ------------------------------ |
| **200** | Rule deleted successfully. |
| **400** | Invalid rule pairs or payload. |
| **401** | Unauthorized action. |
| **404** | Rule or group not found. |
| **405** | Rule type update not allowed. |
| **429** | Too many requests. |
# Get Group
Source: https://interceptor-docs.requestly.com/public-apis/get-group
Learn how to retrieve details of specific groups or all groups using Requestly Interceptor's API
***
This endpoint allows you to fetch a list of all groups in your Requestly Interceptor account. It supports pagination for handling large datasets.
For a live view and to test this API interactively, visit the [API Playground](https://requestly.readme.io/reference/get_groups-1).
***
### Endpoint
* **Method**: GET
* **URL**: `https://api2.requestly.io/v1/groups`
***
### Query Parameters
| **Parameter** | **Type** | **Description** | **Required** | **Default Value** |
| ------------- | -------- | --------------------------------------------------------------------- | ------------ | ----------------- |
| `offset` | Integer | The index from where the results should start. Useful for pagination. | No | `0` |
| `pageSize` | Integer | The number of results to return. Maximum value is `75`. | No | `30` |
***
### cURL Request
```bash theme={null}
curl --request GET \
--url https://api2.requestly.io/v1/groups \
--header 'accept: application/json' \
--header 'x-api-key: your_api_key'
```
***
### Sample Response
```json theme={null}
{
"success": true,
"data": [
{
"createdBy": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"creationDate": 1736059835086,
"currentOwnerId": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"id": "Group_qrszh",
"isFavourite": false,
"lastModifiedBy": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"modificationDate": 1736059835086,
"name": "Group",
"objectType": "group",
"status": "Inactive"
},
... more groups
],
"nextOffset": null,
"total": 50
}
```
***
### Response Codes
| **Status Code** | **Description** |
| --------------- | -------------------------------------- |
| **200** | List of groups retrieved successfully. |
| **400** | Bad Request. |
| **401** | Unauthorized action. |
| **500** | Server error. |
# Get Rule
Source: https://interceptor-docs.requestly.com/public-apis/get-rule
Learn how to retrieve all rules or specific ones using Requestly Interceptor's API with detailed examples.
***
You can either get a list of all your rules or look up a specific rule using its unique ID.
## Get All Rules
Retrieve all rules associated with your Requestly Interceptor workspace. This endpoint supports pagination for managing large sets of data.
For a live view and to test this API interactively, visit the [API Playground](https://requestly.readme.io/reference/get_rules-1).
### Endpoint
* **Method**: GET
* **URL**: `https://api2.requestly.io/v1/rules`
***
### Query Parameters
| Parameter | Type | Description | Required | Default Value |
| ---------- | ------- | ----------------------------------------------------------------------------------------------------------------- | -------- | ------------- |
| `offset` | Integer | The index from where the results should start. Use the value received in `nextOffset` from the previous response. | No | 0 |
| `pageSize` | Integer | Number of results to return. Maximum value is 75. | No | 30 |
***
### cURL Example:
```bash theme={null}
curl --request GET \
--url https://api2.requestly.io/v1/rules \
--header 'accept: application/json' \
--header 'x-api-key: your_api_key'
```
***
### Sample Responses
```json theme={null}
{
"success": true,
"data": [
{
"createdBy": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"creationDate": 1735820120338,
"currentOwnerId": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"description": "hello ",
"extensionRules": [
{
"action": {
"redirect": {
"url": "https://www.bing.com/"
},
"type": "redirect"
},
"condition": {
"excludedInitiatorDomains": [
"requestly.io"
],
"excludedRequestDomains": [
"requestly.io"
],
"isUrlFilterCaseSensitive": true,
"urlFilter": "https://www.google.com/"
}
}
],
"groupId": "",
"id": "Redirect_a9qau",
"isFavourite": false,
"isSample": false,
"lastModifiedBy": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"modificationDate": 1735820120338,
"name": "test",
"objectType": "rule",
"pairs": [
{
"destination": "https://www.bing.com/",
"destinationType": "url",
"id": "8id6k",
"source": {
"key": "Url",
"operator": "Contains",
"value": "https://www.google.com/"
}
}
],
"ruleType": "Redirect",
"schemaVersion": "3.0.0",
"status": "Inactive"
}
// ... other rules
],
"total": 56,
"nextOffset": 31,
}
```
## Retrieve a Specific Rule
This endpoint allows you to fetch details about a specific rule in your Requestly Interceptor account by its unique `ruleId`.
For a live view and to test this API interactively, visit the [API Playground](https://requestly.readme.io/reference/get_rules-ruleid).
### Endpoint
* **Method**: GET
* **URL**: `https://api2.requestly.io/v1/rules/{ruleId}`
***
### Path Parameters
| **Parameter** | **Type** | **Description** | **Required** |
| ------------- | -------- | ------------------------------------------ | ------------ |
| [`ruleId`]() | String | The unique ID of the rule to be retrieved. | Yes |
***
### cURL Example
```bash theme={null}
curl --request GET \
--url https://api2.requestly.io/v1/rules/Redirect_a9qau \
--header 'accept: application/json' \
--header 'x-api-key: your_api_key'
```
***
### Sample Response
```json theme={null}
{
"success": true,
"data": {
"createdBy": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"creationDate": 1735820120338,
"currentOwnerId": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"description": "hello",
"extensionRules": [
{
"action": {
"redirect": {
"url": "https://www.bing.com/"
},
"type": "redirect"
},
"condition": {
"excludedInitiatorDomains": ["requestly.io"],
"excludedRequestDomains": ["requestly.io"],
"isUrlFilterCaseSensitive": true,
"urlFilter": "https://www.google.com/"
}
}
],
"groupId": "",
"id": "Redirect_a9qau",
"isFavourite": false,
"isSample": false,
"lastModifiedBy": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"modificationDate": 1735820120338,
"name": "test",
"objectType": "rule",
"pairs": [
{
"destination": "https://www.bing.com/",
"destinationType": "url",
"id": "8id6k",
"source": {
"key": "Url",
"operator": "Contains",
"value": "https://www.google.com/"
}
}
],
"ruleType": "Redirect",
"schemaVersion": "3.0.0",
"status": "Inactive"
}
}
```
***
### Response Codes
| **Status Code** | **Description** |
| --------------- | ------------------------------ |
| **200** | Rule retrieved successfully. |
| **400** | Invalid rule pairs or payload. |
| **401** | Unauthorized action. |
| **404** | Rule or group not found. |
| **429** | Too many requests. |
# Overview
Source: https://interceptor-docs.requestly.com/public-apis/overview
Welcome to the Requestly Interceptor API documentation!
***
The Requestly Interceptor API empowers you to automate and streamline rule management and integrations within your workflows. Whether you're enhancing CI/CD pipelines or programmatically managing rules, the API offers robust capabilities to meet your needs.
## What Can You Do with the Requestly Interceptor API?
**Rule Management**: Create, update, delete, and retrieve rules such as Redirects, Replace Rules, Modify Headers, and more.
**CI/CD Integration**: Seamlessly integrate rule management into your CI/CD pipelines for automated deployments and updates.
**Data Access**: Fetch and utilize data stored in your Requestly Interceptor account for analytics and reporting.
**Custom Workflows**: Build custom solutions leveraging the API's endpoints to suit unique business requirements.
***
## Getting Started
The API is currently in **BETA**. To access it, you need an API key:
* Each API key is linked to a specific workspace.
* API keys cannot access rules or data outside the associated workspace.
Request your API key by filling out a simple form. Our team will review your request and provide access shortly.
Use your API key to authenticate API requests. Include the key in the header of every request:
```jsx theme={null}
x-api-key:
```
### Explore the Playground
The API Playground allows you to interact with different endpoints while gaining a deeper understanding of API behavior through real-time feedback.
***
## API Structure and Usage
The Requestly Interceptor API is designed with simplicity and scalability, offering a structured rule and group management approach. Here’s a detailed breakdown of its organization and capabilities
### **Rule Management**
The core functionality of the API revolves around rule management. With these endpoints, you can programmatically manage every aspect of your rules:
* **Create Rules**: Add rules for Redirects, Replace Operations, Headers Modifications, Query Parameters, User-Agent Changes, Delays, and more.
* **Update Rules**: Modify existing rules to reflect new requirements or changes.
* [**Retrieve Rules**](/public-apis/get-rule) :
* Fetch all rules in your workspace.
* Retrieve specific rules using unique identifiers.
* [**Delete Rules**](/public-apis/delete-rule): Remove outdated or unused rules to keep your workspace organized.
### **Groups Management**
Efficiently organize your rules by creating and managing groups. The following endpoints are available:
* [**Create a Group**](/public-apis/create-group): Define new groups to categorize rules.
* [**Retrieve Groups**](/public-apis/get-group): Fetch a list of all groups in your workspace.
* [**Update Group Details**](/public-apis/update-existing-groups): Modify the properties of an existing group.
* [**Delete a Group**](/public-apis/delete-group): Remove groups that are no longer needed.
# Update A Specific Groups
Source: https://interceptor-docs.requestly.com/public-apis/update-existing-groups
Learn how to update group details in Requestly Interceptor's API with parameters and example payloads
***
This endpoint enables you to update details such as the name, status, and favorite status of an existing group using its unique ID.
For a live view and to test this API interactively, visit the [API Playground](https://requestly.readme.io/reference/put_groups-id).
***
### Endpoint
* **Method**: PUT
* **URL**: `https://api2.requestly.io/v1/groups/{id}`
***
### Path Parameters
| **Parameter** | **Type** | **Description** | **Required** |
| ------------- | -------- | --------------------------------------------- | ------------ |
| `id` | String | The unique identifier of the group to update. | Yes |
***
### Body Parameters
| **Parameter** | **Type** | **Description** | **Required** | **Default Value** |
| ------------- | -------- | -------------------------------- | ------------ | ----------------- |
| `name` | String | The new name of the group. | Yes | |
| `status` | String | The updated status of the group. | No | `Active` |
| `isFavourite` | Boolean | Pins the group (true or false). | No | `false` |
***
### cURL Request
```bash theme={null}
curl --request PUT \
--url https://api2.requestly.io/v1/groups/Group_qrszh \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--header 'x-api-key: your_api_key' \
--data '{
"name": "Data",
"status": "Active",
"isFavourite": true
}'
```
***
### Sample Response
```json theme={null}
{
"success": true,
"data": {
"id": "Group_qrszh",
"creationDate": 1736059835086,
"modificationDate": 1736059838864,
"createdBy": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"lastModifiedBy": "IUAGkRiEx6XI0B6qCc82qbwroKX2",
"name": "Data",
"objectType": "group",
"status": "Active",
"isFavourite": true
}
}
```
***
### Response Codes
| **Status Code** | **Description** |
| --------------- | ----------------------------------- |
| **200** | Group updated successfully. |
| **400** | The provided group ID is invalid. |
| **401** | Unauthorized action. |
| **404** | The specified group does not exist. |
| **500** | An error occurred on the server. |
# Update Rule
Source: https://interceptor-docs.requestly.com/public-apis/update-rule
Learn how to update existing rules in Requestly Interceptor's API, including parameters and payload structure
***
This endpoint allows you to modify the details of an existing rule. You can update properties like the rule's name, description, status, source, and destination. This endpoint is useful for keeping your rules updated as your requirements evolve.
For a live view and to test this API interactively, visit the [API Playground](https://requestly.readme.io/reference/put_rules-ruleid-11).
## Endpoint
* **Method**: PUT
* **URL**: `https://api2.requestly.io/v1/rules/{ruleId}`
## **Parameters**
### **Path Parameters**
* `ruleId` (string, required): The unique identifier of the rule you want to update.
### **Body Parameters**
| Parameter | Type | Description | Default Value |
| ------------- | ------ | ---------------------------------------------------- | ------------- |
| `name` | string | Name of the rule. | - |
| `description` | string | Description of the rule. | - |
| `objectType` | string | Type of the object. Always set to `rule`. | `rule` |
| `ruleType` | string | Type of the rule. For this schema, it’s `Redirect`. | - |
| `status` | string | Status of the rule: `Active` or `Inactive`. | `Active` |
| `pairs` | array | List of rule pairs defining the redirect conditions. | - |
## **cURL** Request
```bash theme={null}
curl --request PUT \
--url https://api2.requestly.io/v1/rules/Redirect_wi3uJ \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--header 'x-api-key: YOUR_API_KEY' \
--data '{
"objectType": "rule",
"ruleType": "Redirect",
"status": "Inactive",
"name": "Redirect Bing to Google",
"pairs": [
{
"source": {
"key": "Url",
"operator": "Equals",
"value": "https://www.bing.com/"
},
"destination": "https://www.google.com/",
"destinationType": "url"
}
]
}'
```
## Example Response
```json theme={null}
{
"success": true,
"data": {
"id": "Redirect_wi3uJ",
"creationDate": 1736960959780,
"modificationDate": 1760142474884,
"createdBy": "user_id",
"lastModifiedBy": "user_id",
"name": "Redirect Bing to Google",
"description": "",
"ruleType": "Redirect",
"objectType": "rule",
"pairs": [
{
"source": {
"key": "Url",
"operator": "Equals",
"value": "https://www.bing.com/"
},
"destination": "https://www.google.com/",
"destinationType": "url",
"id": "2d9dv"
}
],
"status": "Inactive"
}
}
```
***
## **Request Structure**
### **Body Parameters**
| Name | Type | Required | Default | Description |
| --------------- | ------------------ | -------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **name** | `string` | Yes | | Name of the rule. |
| **description** | `string` | No | | Description of the rule. |
| **objectType** | `string` | Yes | `rule` | Type of the object. For this endpoint, it is always `rule`. |
| **ruleType** | `string` | Yes | | Type of the rule. Possible values are: `Redirect`, `Cancel`, `Replace`, `Headers`, `UserAgent`, `QueryParam`, `Request`, `Response`, `Delay`. |
| **status** | `string` | No | `Active` | Status of the rule, either `Active` or `Inactive`. |
| **pairs** | `array of objects` | Yes | | List of rule pairs specific to the rule type. See details below. |
| **groupId** | `string` | No | | The ID of the group the rule belongs to. If omitted, the rule is ungrouped. |
***
## **Rule Type Details**
Each rule type has a unique structure for its **pairs** of objects. The schemas for each rule type are detailed below:
### **Common Source Schema**
The source object is consistent across all rule types. It has the following structure:
| Property | Type | Required | Description |
| ------------ | -------- | -------- | -------------------------------------------------------------------------------- |
| **key** | `string` | Yes | The key for the source (e.g., `url`, `host`, `path`). |
| **operator** | `string` | Yes | The operator for matching (`Equals`, `Contains`, `Matches`, `Wildcard_Matches`). |
| **value** | `string` | Yes | The value to match against. |
| **filters** | `array` | No | Optional filters for more accurate targeting. |
***
### **Redirect Rule**
* **ruleType**: `Redirect`
* **pairs** schema:
| Property | Type | Required | Description |
| ------------------- | -------- | -------- | ------------------------------------------------------------------------------ |
| **source** | `object` | Yes | The source object for matching (see common source schema). |
| **destinationType** | `string` | Yes | Type of the destination (`u`below`rl`, `map_local`, or `mock_or_file_picker`). |
| **destination** | `string` | Yes | The destination URL value. |
***
### **Cancel Rule**
* **ruleType**: `Cancel`
* **pairs** schema:
| Property | Type | Required | Description |
| ---------- | -------- | -------- | ------------------------------- |
| **source** | `object` | Yes | The source object for matching. |
***
### **Replace Rule**
* **ruleType**: `Replace`
* **pairs** schema:
| Property | Type | Required | Description |
| ---------- | -------- | -------- | ------------------------------- |
| **source** | `object` | Yes | The source object for matching. |
| **from** | `string` | Yes | The target string to replace. |
| **to** | `string` | Yes | The replacement value. |
***
### **Headers Rule**
* **ruleType**: `Headers`
* **pairs** schema:
| Property | Type | Required | Description |
| ----------------- | -------- | -------- | ----------------------------------------- |
| **source** | `object` | Yes | The source object for matching. |
| **modifications** | `array` | Yes | List of header modifications (see below). |
**Header Modification Object:**
| Property | Type | Required | Description |
| ---------- | -------- | -------- | ------------------------------------------------------------------ |
| **header** | `string` | Yes | The name of the header to modify. |
| **type** | `string` | Yes | Modification type (`Add`, `Remove`, or `Modify`). |
| **value** | `string` | No | The value to set for the header (required for `Add` and `Modify`). |
***
### **User-Agent Rule**
* **ruleType**: `UserAgent`
* **pairs** schema:
| Property | Type | Required | Description |
| ------------- | -------- | -------- | ------------------------------- |
| **source** | `object` | Yes | The source object for matching. |
| **userAgent** | `string` | Yes | The User-Agent string to set. |
***
### **Query Param Rule**
* **ruleType**: `QueryParam`
* **pairs** schema:
| Property | Type | Required | Description |
| ----------------- | -------- | -------- | --------------------------------------------------- |
| **source** | `object` | Yes | The source object for matching. |
| **modifications** | `array` | Yes | Array of query parameter modifications (see below). |
**Query Param Modification Object:**
| Property | Type | Required | Description |
| --------- | -------- | -------- | ----------------------------------------------------- |
| **param** | `string` | Yes | The name of the query parameter to modify. |
| **type** | `string` | Yes | Modification type (`Add`, `Remove`, or `Remove All`). |
| **value** | `string` | No | The value to set (required for `Add` and `Modify`). |
***
### **Modify Request Rule**
* **ruleType**: `Request`
* **pairs** schema:
| Property | Type | Required | Description |
| --------- | -------- | -------- | -------------------------------------------------- |
| **type** | `string` | Yes | Type of request modification (`code` or `static`). |
| **value** | `string` | Yes | The request value or code. |
***
### **Modify Response Rule**
* **ruleType**: `Response`
* **pairs** schema:
| Property | Type | Required | Description |
| ----------------------- | --------- | -------- | ------------------------------------------------------------------ |
| **type** | `string` | Yes | Type of response modification (`code` or `static`). |
| **value** | `string` | Yes | The response value or status code. |
| **serveWithoutRequest** | `boolean` | No | Whether to serve the response directly from Requestly Interceptor. |
***
### **Delay Rule**
* **ruleType**: `Delay`
* **pairs** schema:
| Property | Type | Required | Description |
| ---------- | -------- | -------- | ------------------------------- |
| **source** | `object` | Yes | The source object for matching. |
| **delay** | `number` | Yes | Delay value in milliseconds. |
***
## Error Responses
| Status Code | Description |
| ----------- | ---------------------------------- |
| 400 | Rule pairs or payload are invalid. |
| 401 | Unauthorized action. |
| 404 | Rule or group not found. |
| 405 | Rule type update not allowed. |
# Access Control of Session
Source: https://interceptor-docs.requestly.com/sessions/access-control-of-session
Learn how to manage access control for Sessions in Requestly Interceptor, with options for private, shared, and specific access, ensuring secure collaboration
***
Once you get familiar with Sessions, you can dive into managing access control for session recordings. Requestly Interceptor offers flexible **Access Control**, allowing you to decide who can view, delete, and share recorded sessions. These options ensure that your recordings are shared securely with the right people, giving you full control over who has access based on your team's needs.
## **Sharing Options for Recordings**
### **1. Private (Default Option)**
Select this option if you want to keep the recording for personal or future reference only. No one else will be able to access the recording unless explicitly shared.
For recordings made within workspaces, private recordings are visible only to members of that workspace.
### **2. Anyone with the Link**
Choose this option if you want anyone on the internet to be able to access the recording. This is useful for sharing recordings with external stakeholders or collaborators.
Anyone who has the link can view the recording, and no authentication is required.
### **3. Only with Specific People**
This option allows you to restrict access to the recording to specific individuals. It is ideal when you want to share a session with a select team or person, without making it public to others.
For recordings inside workspaces, this option ensures that the recording is visible only to those specified, as well as members of the workspace.
*Here you can enter the email of the people you'd like to share this with.*
The **Start from** option allows users to set a specific timestamp for the session replay, ensuring viewers begin watching from the most relevant point instead of the default starting time.
***
## How to Modify Access Control Settings
### Step 1: Find and Select the Session
Choose the session you want to update.
### Step 2: Click the Share Button
Click the **Share** button to open the sharing options.
### Step 3: Set Access Permissions
* **Private**: Only you can access it.
* **Anyone with the Link**: Anyone with the link can access it.
* **Specific People**: Share with specific people by entering their emails.
### Step 4: Set a Start Time (If Needed)
If necessary, set a start time for the session to begin.
### Step 5: Save the changes
Click **Save** to apply the changes.
***
# Import & View HAR File
Source: https://interceptor-docs.requestly.com/sessions/import-view-har-file
Learn how to generate and import HAR files in Requestly Interceptor to analyze network activity, diagnose issues, and improve web performance
***
HAR ( HTTP Archive ) files store detailed information about the network requests and responses, including URLs, headers, status codes, and timings. This data is useful for diagnosing issues and analyzing web performance.
**SessionBook** is an enhanced version of the HAR file feature in Requestly Interceptor. It not only records HTTP traffic but also captures screen and mouse movements for a more detailed session playback.
## How to Generate a HAR File
To capture and analyze network activity, you can generate a HAR (HTTP Archive) file from any browser's developer tools. Here’s how to create a HAR file using Google Chrome:
### Step 1: Open Google Chrome
Navigate to the webpage you want to analyze.
### Step 2: Open Developer Tools
Right-click anywhere on the page and select **Inspect**, or press `Ctrl + Shift + I` (Windows) or `Cmd + Option + I` (Mac).
### Step 3: Go to the Network Tab
In the Developer Tools panel, switch to the **Network** tab to begin recording network activity.
### Step 4: Start Recording Network Activity
Locate the round icon at the top-left of the Network tab:
* If the icon is **red**, recording is active.
* If it’s **gray**, click the icon to start recording.
### Step 5: Perform the Desired Action
To ensure all network requests are captured, enable **Preserve log** by checking the checkbox next to it. This will keep the recorded data even if you navigate or reload the page.
Please navigate through the page or reload it to capture the network traffic for the action you're analyzing.
### Step 6: Save the HAR File
Once you’ve captured the network traffic, Click the **download icon** in the Network tab to save the HAR File.
***
> Note: If you're using the Requestly Interceptor desktop app, you can also export network sessions directly from the traffic table or the Sessions tab.
## Export a HAR File from the Requestly Interceptor Desktop App
You can export a `HAR file` from captured traffic using the **HTTP Interceptor** while monitoring browser or app traffic. Follow these steps:
### Step 1: Navigate to the Network Table:
Open the **Requestly Interceptor Desktop App** and go to the **Network Table** to begin monitoring traffic.
### Step 2: Connect an App:
Click the **Connect Apps** button to establish a connection between Requestly Interceptor and your app.
### Step 3: Select the Traffic Source:
Choose the source from which you want to intercept traffic (e.g., browser, Android, iOS). For browser traffic, click **Open/Launch** and follow the on-screen instructions. For mobile traffic, follow the specific instructions for connecting Android or iOS.
### Step 4: Download the HAR File:
Once traffic is captured, you can either directly export the HAR file from the traffic table or save the network session and export it later from the Sessions Tab.
***
## **How to Import a HAR File into Requestly Interceptor**
To analyze network activity, you can import a HAR file into the Requestly Interceptor desktop app:
### Step 1: Open the Requestly Interceptor Desktop App
Go to the **Sessions** tab in the sidebar.
### Step 2: Click Import HAR File
Click the **Import HAR File** button to upload your HAR file.
### Step 3: Select the HAR File
Choose the HAR file from your device to upload.
Once you've imported the HAR file, you will see an interface like this:
# Overview
Source: https://interceptor-docs.requestly.com/sessions/overview
Learn when to use Sessions, how to record bug reports or API sessions, and how to share debugging context with your team.
Sessions help you capture the evidence around a problem so it is easier to debug, replay, share, or turn into a mock later.
## When To Use Sessions
Use Sessions when you want to:
* record browser activity, console logs, network logs, and environment context for bug reports
* capture API traffic from the Desktop App for replay, analysis, or bulk mocking
* import HAR files for investigation
* share reproducible debugging context with teammates
You may still encounter older references to **Session Book** in the product or legacy links. In the docs, this workflow is documented under **Sessions**.
## Choose The Right Session Workflow
Use this path when you want browser-focused debugging context such as screen activity, console logs, network logs, and environment details.
Capture reproducible bug reports directly from the browser workflow.
Use this path when you want to record API traffic from the Desktop App, inspect requests and responses, or create mocks from captured traffic.
Record and analyze network traffic from interception workflows.
## First Success Path
Start with browser bug reports if you need user-facing reproduction context. Start with API sessions if the problem is primarily network behavior.
Use [Record Bug Reports](/sessions/record-bug-reports) or [Record API Sessions](/sessions/record-api-sessions) depending on the workflow.
Share the session, import/export HAR files, or use captured traffic to support mocking and debugging flows.
## Explore Sessions
Capture browser activity and rich debugging context for issue reproduction.
Record and analyze traffic captured from interception workflows.
Open and analyze existing HAR files in Requestly Interceptor.
Control who can view and use shared sessions.
Start with HTTP Interceptor if you need to capture traffic before recording a reusable session.
Use captured sessions to create repeatable mocking workflows.
# Record API Sessions
Source: https://interceptor-docs.requestly.com/sessions/record-api-sessions
Learn how to record APIs using Requestly Interceptor Desktop App, save and share API sessions, import HAR files, perform bulk mocking, and replay sessions for debugging.
***
**Recording API sessions** allows you to monitor and debug HTTP traffic between your application and the server. This can significantly improve debugging efficiency by providing insights into network behavior, as well as enhance testing workflows by enabling precise analysis of API interactions.
With the Requestly Interceptor Desktop App, you can capture and analyze network activity effortlessly. This guide will walk you through the steps to create, manage, and utilize API sessions effectively.
This feature is available only on Desktop App.
## How to Create an API Session in Requestly Interceptor
Creating an API session in Requestly Interceptor is straightforward, allowing you to record, import, and analyze network traffic with ease. Here are three methods to get started:
### Save Captured Live Traffic with HTTP Interceptor
One way to create an API session in Requestly Interceptor is by saving captured traffic using the **HTTP Interceptor** while monitoring a browser or an app’s traffic. This allows you to share or analyze the traffic later.
Here's how:
Open the Requestly Interceptor desktop and access the Network Table.
Click the `Connect Apps` button
Choose from where you want to intercept traffic (e.g., browser, Android, iOS). Click **Open/Launch** for browser traffic and follow the instructions for mobile traffic.
As traffic gets intercepted, perform relevant activities. When you're ready to save the session, click the `Save` button.
### Import a HAR File
Another method is to **import a HAR file**, which can be generated from various sources, including browser network sessions, other interceptors, or even Requestly Interceptor's traffic interceptor.
Follow these steps:
Generate and **export the HAR** file from your preferred source.
In the Requestly Interceptor app, go to the **Sessions** tab and click **Import HAR**.
Once imported, you can start analyzing the session data.
### Import a .rqly File
Requestly Interceptor also supports importing its proprietary `.rqly` file format. This is useful for loading sessions captured from browser-based Sessions workflows.
Here's how:
Navigate to the desired session in the web app's Session and click **Download**.
In the Requestly Interceptor Desktop App, click **Import .rqly File** and upload the downloaded file.
You can view the saved session later under the **Sessions** tab on the left side of the app.
***
## Session Interface
### Search and Filters
* **Search URL**: Look for specific requests by entering part of the URL, a wildcard, or a regular expression.
* **Filter by Method**: Narrow requests using HTTP methods like GET, POST, or PUT.
* **Filter by Status Code**: Filter responses by status codes (e.g., 200 for success, 404 for not found).
* **Filter by Resource Type**: Focus on resource types such as CSS files, JavaScript files, or images.
* **Modified Requests**: Check this box to see only requests altered by your applied rules.
* **Clear All**: Reset all filters to view the full list of requests.
### Traffic Table
The main table provides a detailed overview of network requests, including:
* **Time**: The timestamp of each request.
* **URL**: The accessed URLs for better visibility into endpoints.
* **Method**: The HTTP method used (e.g., GET, POST).
* **Content-Type**: The type of content being transmitted (e.g., `text/css`, `application/json`).
* **Status**: The HTTP response status code (e.g., 200, 404).
### Details Section (Bottom Panel)
The bottom panel provides detailed information about selected requests, including
* **Request Details**: View the HTTP method, path, host, and port.
* **Headers**: Inspect request and response headers.
* **Payload**: Check data sent with the request (e.g., for POST requests).
* **Body**: Examine the response body.
* **Preview**: Render response content, such as HTML or CSS, if applicable
### Action Buttons
* **Create Mocks**: Simulate backend responses for testing and development without relying on an actual server. You can also perform **bulk mocking** to create multiple mock responses at once, streamlining the testing process.
* **Delete Sessions**: Remove old or unnecessary sessions to keep your workflow organized.
* **Download HAR Files**: Export HTTP Archive (HAR) files to analyze network activity and debug issues easily.
## Additional Features
### Bulk Mocking
Create multiple mock responses at once to save time and simplify your testing. This feature lets you simulate different backend scenarios, speeding up both development and testing.
With Bulk Mocking, you can quickly create mock responses for selected requests in a session, streamlining your workflow. Once your mocks are created, you can view and manage them easily.
For more detailed instructions, check out our Bulk Mocking Guide.
### Saving and Sharing Sessions
You can keep your session data for later use or **share it** with others. Use the **Export HAR** option to download session data, which can be shared or re-imported into Requestly Interceptor. To learn more, visit the **Import/View HAR file page**.
### Creating Rules from Captured Sessions
Requestly Interceptor allows you to use captured sessions to create rules tailored to specific testing scenarios. This method helps replicate real-world conditions effectively. Here's how you can leverage sessions to define rules:
**Popular Use Cases**
* **Redirect Requests:** Create rules to reroute specific URLs to alternative endpoints for testing purposes.
* **Modify Headers:** Adjust request or response headers to simulate various environments or configurations.
* **Delay Responses:** Introduce network delays to observe how your app handles slow response times.
Here’s how to create a Rule from Captured Sessions:
Open Your Session and Right-click any request from the traffic table.
Choose a rule type (e.g., Redirect URL, Modify Header).
Configure the rule as needed for your testing scenario.
Click `Save` to finalize and apply the rule.
### Edit and Replay
The Edit and Replay feature lets you send API requests to an endpoint and modify various parameters like headers, body, query parameters, and more. This functionality acts as an integrated API client within your sessions, making it easier to test and modify API requests directly.
Here’s how to use Edit and Replay :
In your session, choose the interaction or API request you want to analyze. **Right-click** the session and click **Edit and Replay**.
Review the recorded parameters, including headers, body, and query parameters, to understand the request behavior.
After analyzing the session, click the **Send** button to resend the modified request and debug the issue effectively.
# Record Bug Reports
Source: https://interceptor-docs.requestly.com/sessions/record-bug-reports
Learn how to record screen, console logs, network logs, etc then securely share them to speed up issue resolution.
***
Requestly Interceptor **Sessions** helps you capture and share detailed bug reports by recording browsing sessions along with mouse movements, clicks, network logs, console logs, environment details, and LocalStorage changes. It provides the information developers need to reproduce and debug issues without relying only on written reproduction steps.
Let’s see how to record a bug report, save it, and share it with your team.
This feature is supported in Browser Extensions only.
## Configure Session Recording
To begin using **Sessions**, the first thing you'll need to do is **set up your pages**. This ensures that the right pages are ready for recording.
Go to the **Sessions** tab from the left-hand menu in the Requestly Interceptor web app.
Click on **Settings**.
Choose one of the following options:
* **All Pages**: Record sessions on all the websites you visit.
* **Specific Pages**: Record only on specific web pages matching the criteria. Websites and web pages can be filtered based on URL or Hostname and matched using Equals, Contains, RegEx, and Wildcard conditions on the string you type in the source URL field.
If selecting **Specific Pages**, add the source condition, then click **Save**. You can add multiple matching conditions by clicking the **Add Page Source** button.
Once everything is set up, you can **start recording a session**, which will capture all user actions like clicks, page changes, and mouse movements.
## Recording Sessions
To record a session, you can either use manual recording, where you start and stop recording sessions as needed, or auto-recording mode, which automatically captures sessions based on predefined settings.
### Auto Recording Mode
This mode captures user interactions, such as clicks, page transitions, and mouse movements, with sessions capped at 5 minutes for optimal browser performance. Sessions are temporarily stored in local storage, discarding older activity for efficiency, until saved or shared.
Visit a webpage where a bug occurs or any webpage where you want to test it.
Click the **Requestly Interceptor** extension icon in your browser toolbar.
Pin Requestly Interceptor to your toolbar, for faster access.
Click on **Watch Last 5 Min Replay** in the popup. If you have configured Requestly Interceptor to auto-record only selected domains then it will only be available on those domains.
The recorded session draft will open in a new browser tab. There you can either save it or share it with developers.
Sessions are stored in LocalStorage of your browser until you save them on the cloud or share them by creating a link.
### Manual Recording
If Session Recording hasn’t been pre-configured for a specific webpage, you can manually record sessions by following these steps.
Open the page that you want to record.
Open the **Requestly Interceptor** extension popup from your browser toolbar.
Click the **Record this tab** button to begin capturing session data.
Once you're finished, click the **Stop & Watch** button, either from the extension popup or from the Requestly Interceptor widget at the bottom-left corner.
## Saving a Session
After recording the session, it enters a draft state, allowing you to review and make edits. You can trim the video, add a title and description, and make any other adjustments before saving it. During this time, the session is stored in the local storage of your browser only.
Open the session in the extension popup.
Replay the video and review details such as:
* Console logs
* Network logs
* Environment details
* Local storage changes
Optionally, you can trim the video to skip irrelevant portions.
Add a description to explain the bug or include additional information.
Click **Save Recording** to:
* Save online on the Requestly Interceptor cloud.
* Download locally if needed.
Before saving, use the checkboxes to include or exclude **network logs** and **console logs** as per your needs. Request headers are not stored for security reasons, as they generally contain authentication information.
## Sharing a Session
Once a recording is saved, you can share it with your team using different access controls:
* **Private**
* **Anyone with the Link**
* **Only with Specific People**
For more detailed steps on how to share and manage access, visit the Access Control section.
Click the **Copy Link** to get the shareable URL.
If sharing with specific people, they’ll receive an email notification with the link.
# Disable System Wide Proxy (MacOS)
Source: https://interceptor-docs.requestly.com/troubleshoot/http-interceptor/disable-system-wide-proxy-macos
Guide to disable system wide proxy in macos
Incase the app has shut down suddenly while you had the system wide proxy set, here are the steps to make sure that system wide proxy settings have been disabled on MacOS
The steps are slightly different for before and after macOS 13
### **macOS 13 Ventura or later**
### **Before macOS 13 Ventura**
# How to Install Requestly Interceptor CA Certificate in Windows Certificate Manager
Source: https://interceptor-docs.requestly.com/troubleshoot/http-interceptor/install-certificate-windows
Steps to install Requestly Interceptor CA (Certificate Authority) certificate to intercept HTTPS network traffic on Windows
To intercept HTTPS network traffic, you need to install the Requestly Interceptor CA (Certificate Authority) certificate to your Windows certificate manager. There are two methods: automatic and manual.
Launch the Requestly Interceptor Desktop App on your Windows system
Click on **"Enable Requestly Interceptor System-wide"**
* Click on **"Install & Trust"** button
* A popup will automatically appear to install the certificate
* Follow the prompts to complete the installation
If the automatic method doesn't work, follow these manual steps:
* In Requestly Interceptor Desktop App, go to the System Proxy popup
* Click on **Manual** tab
* Click on **Save Certificate** button
* Save the CA certificate to any location on your system (e.g., Desktop or Downloads folder)
* Press `WIN + R`, type `certmgr.msc` and press Enter
* Navigate to: **Trusted Root Certification Authorities → Certificates**
* Right-click on **Certificates** → **All Tasks → Import**
* Browse and select the CA certificate file you downloaded in step 1
* Click **Finish**
* To verify if HTTPS traffic is being intercepted, connect to the proxy
* Check that secure (HTTPS) traffic is now being logged in Requestly Interceptor
### Troubleshooting
If you're still unable to intercept HTTPS traffic after following these steps, please ensure:
* The CA certificate was imported to the correct location (Trusted Root Certification Authorities)
* The proxy is properly configured and running
* Try restarting your browser/ application after CA certificate installation
# Cannot Intercept Requests from Localhost
Source: https://interceptor-docs.requestly.com/troubleshoot/http-interceptor/intercepting-requests-from-localhost
On macOS, any requests to localhost do not go through the configured proxy. To get around this we need to rename localhost to something else for it to be captured by Requestly Interceptor. There are two ways you can do this
## **Solution 1: configure rq.proxy to point to localhost in** `/etc/hosts`
1. Open `/etc/hosts` as a `sudo` user . For eg. using `sudo nano /etc/hosts` . You will be prompted to enter your password
2. Add the following entries to this file:
```plaintext theme={null}
127.0.0.1 rq.proxy
::1 rq.proxy
```
3. Save the changes into this file.
4. Replace all your calls to [**localhost**](http://localhost/) with `rq.proxy` . For eg. [**http://localhost:3000**](http://localhost:3000/) → [**http://rq.proxy:3000**](http://rq.proxy:3000/)
5. If you are using Chrome you might need to also stop automatic redirects from http → https for this domain:
1. Go to `chrome://flags`
2. search for the `#unsafely-treat-insecure-origin-as-secure` flag
3. set the value as [`http://rq.proxy`](http://rq.proxy/)`, `[`http://localhost.requestly.io`](http://localhost.requestly.io/) (the second domain is used in the next solution, incase this one doesn’t work)
## **Solution 2: Use** [**localhost.requestly.io**](http://localhost.requestly.io/) **instead**
We have setup this domain to point to 127.0.0.1 (i.e. your [**localhost**](http://localhost/)). But for this to work you will have to follow the steps to stop automatic redirects from http → https.
As mentioned earlier, to do this in chrome:
1. Go to `chrome://flags`
2. search for the `#unsafely-treat-insecure-origin-as-secure` flag
3. set the value as [`http://localhost.requestly.io`](http://localhost.requestly.io/)
Once that’s done, replace all your calls to [**localhost**](http://localhost/) with [`localhost.requestly.io`](http://localhost.requestly.io/) . For eg. [**http://localhost:3000**](http://localhost:3000/) → [**http://localhost.requestly.io:3000**](http://localhost.requestly.io:3000/)
**Note: You might need to modify the source condition of any rules that were originally meant to be applied on localhost**
# System Wide Proxy Not Working (macOS)
Source: https://interceptor-docs.requestly.com/troubleshoot/http-interceptor/system-wide-proxy-not-working-macos
Steps for Troubleshooting Requestly Interceptor System wide proxy on OSX
### **Check Proxy**
The steps to do this vary slightly based on your macOS version
#### **macOS 13 Ventura or later**
Check whether Web Proxy (HTTP) and Secure Web Proxy (HTTPS) are enabled or not. And the Port mentioned there matches the port mentioned on the header of Requestly Interceptor Desktop App
#### **Before macOS 13 Ventura**
Check whether Web Proxy (HTTP) and Secure Web Proxy (HTTPS) are enabled or not. And the Port mentioned there matches the port mentioned on the header of Requestly Interceptor Desktop App
### **Check Certificate**
For Requestly Interceptor to intercept HTTPS traffic, you need to install Requestly Interceptor Certificate in the keychain
* Open keychain access (Press cmd + enter and then type "keychain")
- Select login keychain
* Check whether RQProxyCA is present and trusted or not.
# Troubleshooting Proxy Not Shown Issue (Windows)
Source: https://interceptor-docs.requestly.com/troubleshoot/http-interceptor/troubleshooting-proxy-not-shown-windows
Steps to troubleshoot when proxy is not shown in Requestly Interceptor Desktop App on Windows
If you're seeing a "No Proxy" issue in the Requestly Interceptor Desktop App on Windows, follow these troubleshooting steps:
### Troubleshooting Steps
Verify that port 8281 is not being used by another application. Open Command Prompt and run:
```
netstat -ano | findstr :8281
```
This will show you the Process ID (PID) using this port. Then identify which process is using the port by running (replace `7136` with the PID from the previous command):
```
tasklist /FI "PID eq 7136"
```
If the port is being used by an application other than Requestly Interceptor:
* Go to Requestly Interceptor Settings
* Change the default proxy port to an available port
If Requestly Interceptor is using port 8281 but you still see the "No Proxy" issue:
* Get your local `IPv4` address by running `ipconfig` in Command Prompt
* Try connecting to the proxy manually using your local IP and port 8281
* Configure your system or browser to use this proxy: `:8281`
### Still Having Issues?
If the above steps don't resolve your issue, please reach out to us via [email](mailto:contact@requestly.io) for further assistance.
# SSL Certificate Issues with Safari
Source: https://interceptor-docs.requestly.com/troubleshoot/http-interceptor/troubleshooting-safari
Resolve SSL certificate trust issues in Safari. Learn how to regenerate SSL certificates and fix interception errors.
If you're experiencing trust issues or certificate warnings when using Requestly Interceptor to intercept traffic in Safari or via the system-wide proxy, it may be due to an invalid or untrusted Root Certificate.
**Error indication:** You may see a security warning or certificate error in your browser (especially Safari) when Requestly Interceptor attempts to intercept traffic.
This typically indicates that the Requestly Interceptor Root Certificate has expired, been invalidated, or is not trusted by the system.
## Solution: Regenerate Requestly Interceptor SSL Certificates
Follow these steps to resolve certificate trust issues:
* Open the Requestly Interceptor desktop application.
* Click on the Settings Icon located at the top right.
* Inside the Settings, find and click the `Regenerate` button.
* This action regenerates the SSL certificates.
* The application will automatically close to complete the regeneration process.
* Relaunch the app and start intercepting traffic again. The previously encountered error should now be resolved.
# Troubleshooting: Untrusted SSL certificate
Source: https://interceptor-docs.requestly.com/troubleshoot/http-interceptor/troubleshooting-untrusted-ssl-certificate
Safari does not support setting a proxy on the browser instance due to technical constraints. Therefore, we have to set up a system-wide proxy to connect to Safari. This may lead to some issues, which can be resolved by following troubleshooting steps:
Before following the troubleshooting steps, make sure you have done both of these setup for Safari:
1. **Make sure to launch Safari App from the Connected Apps modal.** In case Safari doesn't open automatically, you can open it yourself also.
2) Try opening [**https://amiusing.requestly.io/**](https://amiusing.requestly.io/) after launching Safari. If it shows `Failure` message, then it indicates that traffic is not being intercepted by Requestly Interceptor and your proxy isn't set up properly. Follow the below steps to troubleshoot the most common problems with setting up Safari.
### **System wide proxy does not work with VPN**
Safari connection might not work with VPN because of the system-wide proxy setup. **If you are using Requestly Interceptor with VPN, you need to disable VPN first, then launch Safari from** `Connected Apps` **and then restart your VPN.**
> ***In our internal testing we found that TunnelBlick and the OpenVPN work well with Requestly Interceptor system wide proxy running. In case you face issues working with these or any other VPN client, feel free to reach out at*** [***contact@requestly.io***](mailto:contact@requestly.io) ***or*** [***raise an issue***](https://github.com/requestly/requestly/issues/new?assignees=\&labels=bug\&labels=vpn\&projects=\&template=bug-report.yml\&title=bug%3A+)
### **Verify Proxy**
The steps to do this vary slightly based on your macOS version
#### **macOS 13 Ventura or later**
1. Open System Preferences
2) Type Proxies in Search
3. Select Proxies
4) Check whether Web Proxy (HTTP) and Secure Web Proxy (HTTPS) are enabled or not. And the Port mentioned there matches the port mentioned on the header of Requestly Interceptor Desktop App
#### **Before macOS 13 Ventura**
1. Open System Preferences
2) Go to Network
3. Select Advanced
4) Go to Proxies
5. Check whether Web Proxy (HTTP) and Secure Web Proxy (HTTPS) are enabled or not. And the Port mentioned there matches the port mentioned on the header of Requestly Interceptor Desktop App
### **Validate that Certificate is trusted**
For Requestly Interceptor to intercept HTTPS traffic, you need to install Requestly Interceptor Certificate in the keychain
* Open keychain access (Press cmd + enter and then type "keychain")
- Select login keychain
* Check whether RQProxyCA is present and trusted or not.
### **Check your Firewall**
Check if you are using any Firewall software like Sophos. Firewalls generally block web proxies for security reasons and mistake Requestly Interceptor as a web proxy but Requestly Interceptor only runs on yourlocal device. Sending them an email will get Requestly Interceptor unblocked for you.
# Unable to intercept web traffic on browser, mobile, or emulator
Source: https://interceptor-docs.requestly.com/troubleshoot/http-interceptor/unable-to-intercept-web-traffic-on-browser-mobile-or-emulator
Troubleshooting guide to resolve common interceptor issues
Use this page as a decision tree when setup looks complete but traffic is still missing from Requestly Interceptor.
## Start With The Fastest Checks
Before diving into platform-specific troubleshooting, confirm these basics:
* Requestly Interceptor is running and the correct browser, device, or runtime is connected
* you completed the relevant [HTTP Interceptor setup guide](/interceptor/overview)
* the traffic you expect is actually leaving the app or browser
* you are looking in the correct interception view
## Choose The Symptom That Matches Your Issue
HTTPS traffic usually fails when the certificate is missing or not trusted.
Localhost and `127.0.0.1` need additional setup.
Revisit the matching browser or runtime setup path first.
Verify proxy, network, and certificate setup for the device or emulator.
## Browser And System-Wide Troubleshooting
### Only HTTP Traffic Is Intercepted
HTTPS traffic usually means the SSL certificate is not installed or trusted correctly.
* Follow [Troubleshooting Untrusted SSL Certificate](/troubleshoot/http-interceptor/troubleshooting-untrusted-ssl-certificate)
* Restart the browser or app after updating certificate trust
### Localhost Traffic Is Missing
Intercepting `localhost` or `127.0.0.1` requires extra configuration.
* Follow [Intercepting Requests from Localhost](/troubleshoot/http-interceptor/intercepting-requests-from-localhost)
### Safari-Specific Problems
Safari can require certificate regeneration and a full app restart.
* Follow [Troubleshooting Safari](/troubleshoot/http-interceptor/troubleshooting-safari)
## Mobile Devices And Emulators
### Device Is Connected But Traffic Is Missing
Check all of the following:
* the device and desktop app are on the same network
* the proxy settings match the Requestly Interceptor desktop app
* the SSL certificate is installed and trusted
* the correct setup guide was followed for the device or simulator
Use these setup references:
* [Android devices](/interceptor/desktop-app/android-devices)
* [Android emulator](/interceptor/desktop-app/android-simulator-interception)
* [iOS devices](/interceptor/desktop-app/ios-devices-interception)
* [iOS simulator](/interceptor/desktop-app/ios-simulator-interception)
### Emulator Is Not Detected
Restart the Requestly Interceptor Desktop App and reconnect the emulator. If the emulator still does not appear, re-run the matching platform setup steps.
### Only Some Mobile Apps Are Intercepted
This is commonly caused by SSL pinning. Proxy-based tools cannot intercept pinned secure traffic unless the app supports it.
* Review the SSL pinning section in [Android devices](/interceptor/desktop-app/android-devices#ssl-pinning-if-required)
## Other Common Causes
### Blocked Domains
Make sure you did not exclude the target domain from interception.
* See [How to Avoid Intercepting Certain Domains](/guides/how-to-avoid-intercepting-certain-domains-on-the-desktop-app)
## Still Need Help?
If the issue persists, collect these details before contacting support:
* where you are intercepting from: browser, system-wide, mobile device, emulator, terminal, or Node.js
* operating system and Requestly Interceptor version
* whether HTTP works while HTTPS fails
* whether localhost traffic is involved
* any visible proxy, certificate, or console errors
# Error on saving rule
Source: https://interceptor-docs.requestly.com/troubleshoot/http-rules/error-on-saving-rule
If you encounter an error while saving a rule in Requestly Interceptor, follow the steps below to identify and resolve the issue:
## 1. Check Console for Error Details
Open the **Developer Console** in your browser (Right-click → Inspect → Console tab).\
You will find an error message logged along with the **Rule ID** that caused the issue.
This information is essential for debugging or sharing with the support team if needed.
## 2. Common Errors and Resolutions
### a. Regex Size Limit Exceeded
If the error message indicates that the regex exceeds the supported size limit, please refer to this issue for known limitations and potential workarounds:\
[Regex Size Limit Issue #1690](https://github.com/requestly/requestly/issues/1690)
### b. Invalid Regex / Unsupported Lookaheads
If the error message mentions *"Invalid regex"* or unsupported syntax such as **lookaheads**, it means the pattern is not compatible with the regex engine we use.
Requestly Interceptor uses **RE2-compatible regular expressions**, as required by **Chrome's Manifest V3** security model.\
This is a technical limitation imposed by Chrome, and not something we can bypass.
For reference on RE2-compatible syntax, you can visit:\
[RE2 Syntax Documentation](https://github.com/google/re2/wiki/Syntax)
## 3. Still Facing Issues?
If your error does not fall under the above categories, or you're unsure how to proceed, please:
* Note the **error message** from the console.
* Contact our support team or file an issue with details on [GitHub](https://github.com/requestly/requestly/issues).
# Rule changes not reflecting in Chrome DevTools
Source: https://interceptor-docs.requestly.com/troubleshoot/http-rules/rule-changes-not-reflecting-in-chrome-devtools
Requestly Interceptor rule changes may not show in Chrome DevTools, learn why and how to verify they’re working.
Some rule modifications made using Requestly Interceptor may **not appear** in Chrome’s Network DevTools, even though they are **successfully applied** in the background.
### Why This Happens
This primarily affects:
* **Modify Response Rule**
* **Modify Response Headers Rule**
When these rules are applied, Requestly Interceptor intercepts and modifies the response **after** it has been received by the browser, but **before** it's delivered to the page. However, Chrome DevTools continues to display the **original unmodified response** because of technical limitations in the browser’s extension APIs.
In short, your modifications **do take effect**, but they **won’t be reflected** in the Network tab of DevTools.
### How to Confirm That Modifications Are Working
To verify that your rule is working as expected:
* Follow this guide to [validate rule execution in your browser](/http-rules/advanced-usage/validate-rules-execution)[.](/http-rules/advanced-usage/validate-rules-execution)
* Check if the application is behaving according to your changes (e.g., modified data is rendered on the page).
* Use `console.log()` or inspect values in the page context (e.g., responses received by `fetch()` or `XMLHttpRequest`).
* Add temporary debug markers (e.g., a test field in a JSON response or a custom response header) and verify their usage in the application logic.
# Rules Not working
Source: https://interceptor-docs.requestly.com/troubleshoot/http-rules/rules-not-working
Having trouble with your rules? Follow this step-by-step checklist to quickly identify and resolve common issues with the Requestly Interceptor browser extension.
If your Requestly Interceptor rules are not applying, use this checklist in order. Most issues come from extension permissions, paused Requestly Interceptor state, inactive groups, or rule-type limitations.
## Start Here
Check these basics first:
* the Requestly Interceptor extension is installed and enabled
* site access is allowed for the page you are testing
* Requestly Interceptor is running and not paused
* the relevant rule group is turned on
* you refreshed the page or retriggered the request after saving the rule
## 1. Confirm Extension Permissions
Go to `chrome://extensions/` in your browser.
Find the Requestly Interceptor extension and click **Details.**
Under **Site access**, choose **"On all sites"**.
## 2. Ensure the Extension Is Enabled
Go to `chrome://extensions/`
Make sure the toggle for Requestly Interceptor is **enabled** (blue).
## 3. Check If the Rule Group Is Active
Groups allow you to organize rules into logical groups and enable/disable them in one go.
Visit the
Requestly Interceptor dashboard
.
Find the group that contains your rule.
Make sure the toggle for that group is switched **on**
## 4. Activate the Extension (If Disabled)
Locate and click the Requestly Interceptor icon in your browser’s toolbar to open the menu.
Click the Requestly Interceptor icon in your browser’s toolbar and find the toggle labeled "Requestly Interceptor paused." Click the toggle to activate Requestly Interceptor. The label will change to "Requestly Interceptor running," confirming activation.
Refresh your browser page to ensure that Requestly Interceptor’s rules are properly applied.
## 5. Recheck The Rule Match
Before assuming the rule is broken, confirm that it actually matches the request:
* the URL condition matches the request you are testing
* the rule type supports the traffic you are trying to change
* the target page is not a browser-internal page such as `chrome://`
Use [Test This Rule](/http-rules/advanced-usage/test-rules) to verify whether the rule conditions match the request you expect.
## **Common Issues by Rule Type**
> Some rule types in Requestly Interceptor have specific behaviors or limitations. Here's what you need to know for each one:
### Modify API Response
**Not visible in Chrome DevTools**\
API response modifications made by Requestly Interceptor don’t show up in the browser’s DevTools, but they’re still applied in the background.
**Only works with XHR/Fetch requests**\
Modify API Response **can’t modify** HTML, CSS, or other static files in the extension. For that, use the [Desktop App](https://requestly.com/downloads/desktop/).
### Modify Request Body
Only works with **XHR** and **Fetch** requests
### Modify Response Headers
Response Headers modification done by Requestly Interceptor are not visible in Browsers devtool but they are actually modified.
### Delay Request
In the browser extension, delays are automatically capped to prevent performance issues. XHR/Fetch requests can be delayed up to 5,000 ms, while other resources (like JS, CSS, images) support up to 10,000 ms. For unlimited delays, switch to the **Desktop App**
### Insert Script Rule
**Inline JavaScript is ignored when using the URL option**\
When you choose the **URL** method, only the external script is loaded. Any inline JavaScript written between the `