Forem: Requestly

Introducing Examples in Requestly

kanishkrawatt — Wed, 18 Mar 2026 09:51:00 +0000

Testing APIs often means repeating the same request again and again with slight variations. Changing parameters, tweaking headers, modifying payloads, and trying edge cases can quickly become repetitive and error prone.

That’s why we’re introducing Examples in Requestly — a simple way to save, organize, and reuse different versions of your API requests without touching the original.

What are Examples?

Examples are saved snapshots of an API call, including both the request and its response.

Each example captures:

Query parameters
Headers
Request body
Response status code
Response body
Response headers

You can attach multiple examples to a single request, all stored under it in the sidebar. This makes it easy to move between different scenarios without duplicating or rewriting requests.

Why this matters

Test multiple scenarios faster

Instead of manually editing the same request over and over, you can save different cases such as:

Valid responses
Edge cases
Error states

And switch between them instantly.

Keep everything organized

Examples are neatly stored under the original request in the sidebar. No clutter. No duplicate requests. Just structured workflows.

Share exact configurations with your team

Every example is available within your workspace, so your team can:

Use the same request setups
Debug issues faster
Stay aligned on API behavior

Revisit past responses anytime

Each example stores both the request and its response. This means you can go back and inspect exactly what happened without re-running anything.

How it works

1. Save any request-response as an example

It includes both the request configuration and the response it returned. This captures everything in one place, so you can reuse or revisit it anytime.

2. Access from the sidebar

Examples appear as child items under the main request. Expand the request to view all saved examples and open them in a new tab.

3. Manage with ease

You can:

Rename examples for clarity
Duplicate them to create variations
Delete ones you no longer need

Everything is designed to keep your workflow flexible and clean.

4. Use examples as templates

Want to create a new request based on an existing setup? Just use an example as a template and start fresh without modifying the original.

Built for real API workflows

Request Examples are designed for how developers actually work:

Iterating on APIs
Testing multiple scenarios
Collaborating across teams
Debugging faster

It removes friction and lets you focus on what matters: building and testing APIs efficiently

Best Postman Alternative in 2026: Faster API Client for Developers

kanishkrawatt — Fri, 13 Mar 2026 06:28:00 +0000

API development tools have evolved significantly over the past decade. What began as simple HTTP request tools has grown into complex platforms for testing, documentation, monitoring, and collaboration.

For many developers, Postman has long been the default API client. However, the Postman pricing changes introduced in 2026 have pushed many developers and small teams to start searching for Postman alternatives that are simpler, faster, and more flexible.

At the same time, tools like Requestly are emerging as strong contenders for developers who want a lightweight API client without the complexity of a full platform.

In this article, we’ll cover:

What changed in Postman’s 2026 pricing model
Why developers are searching for a Postman alternative
How to import Postman collections into another API client
Why lightweight API testing tools are gaining popularity
How Requestly provides a fast and developer-friendly API client

Postman Pricing Changes in 2026

In March 2026, Postman introduced a major overhaul to its pricing structure. The goal was to simplify the platform by removing fragmented add-ons and consolidating features into fewer plans.

The new structure consists of four tiers:

Free
Solo
Team
Enterprise

One positive change was the removal of many usage restrictions. Activities such as running collections or performing automated testing are now unlimited across all plans, including the free tier.

This change reflects how large teams actually work today: running frequent tests and validating APIs continuously during development.

However, the new model introduced a major limitation that has significantly impacted small teams.

The End of Free Team Collaboration

The biggest change in Postman’s pricing update is the restriction of the Free plan to a single user.

Previously, small teams of up to three developers could collaborate for free using shared workspaces. This option no longer exists.

Now, collaboration requires upgrading to the Team plan at $23 per user per month.

For many developers searching for a free Postman alternative, this change has become the main trigger for exploring other API testing tools.

Example: Cost for a Small Team

Per year Cost for a team of three developers:

Cost: 3 * 228 = $684

This means a small team now spends $684 per year just to collaborate in Postman.

For startups and indie developers, that cost can feel unnecessary when they simply need a fast API client to send requests and test endpoints.

Why Developers Are Searching for a Postman Alternative

As Postman expanded into a full API lifecycle platform, the tool naturally became heavier.

For developers already running:

IDEs
Docker containers
browsers
databases

a heavy API client can slow down development workflows.

This has created demand for lightweight Postman alternatives that focus on the core job developers actually need:

Sending HTTP requests
Testing APIs
Inspecting responses
Running quick automated tests

Without the overhead of a large platform.

A Lightweight Postman Alternative: Requestly

Requestly offers a modern API client designed for developers who want speed, simplicity, and flexibility. Requestly focuses on making API testing fast and accessible.

Key advantages include:

For developers looking for a Postman alternative for API testing, Requestly provides a streamlined experience without sacrificing essential functionality.

API Testing Without Login or Setup

One common frustration with developer tools today is the mandatory sign-in requirement.

Many API clients require users to create an account before they can even send their first request.

Requestly removes that barrier with a login-free API client.

Developers can immediately:

Launch the tool
Send API requests
Inspect responses
Start testing endpoints

This makes Requestly ideal for:

Quick endpoint debugging
Learning APIs
Testing third-party services
Rapid development workflows

If you’re searching for an API client without login, this is one of Requestly’s most developer-friendly features.

Import Postman Collections in One Click

One of the biggest concerns when switching tools is losing existing work.

Most teams already have dozens or even hundreds of API collections built in Postman.

Requestly makes migration simple by supporting direct import of Postman collections.

How to Import from Postman

The process typically takes less than a minute:

Export your collection from Postman
Open Requestly’s API client
Import the collection file

Requestly automatically maps:

folders
requests
headers
parameters
environment variables

This allows developers to continue using their existing API workflows without losing any work.

💡If you have 100+ APIs and looking for developer help, reach out to us here for migration support.

Built-in API Automation and Testing

Modern API development requires automated validation.

Requestly supports JavaScript-based scripting for writing tests and validations.

Developers interact with the API request and response using the rq object.

Example: Validate Response Status


rq.test("Status is 200", () => {
 rq.expect(rq.response.code).to.equal(200);
});

Example: Save Data from Response


rq.environment.set("token", rq.response.json().access_token);

These scripts allow developers to:

validate responses
store dynamic variables
create automated testing workflows

For developers familiar with Postman scripts, the learning curve is minimal.

Local-First API Development

API collections can be stored directly on the developer’s machine instead of requiring cloud synchronization.

This offers several advantages:

Better Security

Sensitive API keys and tokens remain on local devices.

Faster Performance

Local storage eliminates network latency when loading large collections.

For developers searching for a local API client alternative to Postman, this approach can significantly improve productivity.

Postman vs Requestly: Choosing the Right API Client

Both tools are powerful, but they serve different developer needs.

Choose Postman if:

Your team needs full API lifecycle management
You require built-in monitoring and governance
You need advance AI for your APIs

Choose Requestly if:

You want a lightweight Postman alternative
You need a fast API client for daily testing
You prefer tools that work without login requirements
You want to import Postman collections easily

The Future of API Client

The API development ecosystem is becoming more diverse.

Large platforms like Postman are evolving into a comprehensive API operating system, offering governance, AI assistance, monitoring, and collaboration features.

Meanwhile, developer-focused tools like Requestly are proving that many teams simply want a fast, flexible API client without the complexity of a large platform.

As developers evaluate tools in 2026 and beyond, the choice often comes down to priorities:

Platform governance and enterprise workflows
Or lightweight tools optimized for developer speed

For teams looking to move away from heavier tools, Requestly is emerging as one of the best Postman alternatives for modern API testing.

Introducing Dynamic Variables: Generate Realistic Test Data Instantly

kanishkrawatt — Mon, 09 Mar 2026 07:32:00 +0000

Dynamic variables are built-in values that are generated automatically at request execution time. No manual edits. No helper scripts. No duplicate test data issues. If you regularly need timestamps, random values, UUIDs, or unique identifiers in your API requests, dynamic variables handle it for you automatically.

Unlike environment, collection, or global variables that you define and manage yourself, dynamic variables are available out of the box and generate a fresh value every time a request runs. Under the hood, Requestly uses Faker.js to generate realistic test data, so your payloads don’t look fake or repetitive.

What are dynamic variables?

Dynamic variables are special placeholders that resolve to automatically generated values at runtime. They use a $ prefix and are accessed with this template syntax:

{{$variableName}}

Every time the request executes, the variable produces a new value.

For example:


{{$randomUUID}} → Generates a new UUID
{{$timestamp}} → Current UNIX timestamp
{{$randomInt}} → Random integer
{{$guid}} → GUID-style identifier

The key difference: you don’t define these. They’re built-in and ready to use.

Why generating test data is a pain

Developers and QA teams run into the same problems again and again:

Reused emails or user IDs cause signup and uniqueness checks to fail.
Manually editing payloads for each run is slow and error-prone.
Tests break when data already exists in the database.

Dynamic variables take those problems off your plate by producing fresh, realistic inputs every time.

Using Dynamic Variables in Templates

You can use dynamic variables anywhere inside a request: URL, Query parameters, Headers, Request body.

Example request body:


{

"id": "{{$randomUUID}}",

"email": "{{$randomEmail}}",

"createdAt": "{{$timestamp}}"

}

Each execution generates a unique user profile

Using Dynamic Variables in Scripts

Dynamic variables are also accessible inside scripts.

rq.$variableName()

Example:


const userId = rq.$randomUUID();

const timestamp = rq.$timestamp();

const email = rq.$randomEmail();

Notice they are called like functions in scripts.

Variable Arguments

Some dynamic variables support optional arguments to customize output.

Template syntax:

{{$variableName arg1 arg2 …}}

Example:


{

"id": "{{$randomAlphaNumeric 10}}",

"email": "{{$randomEmail 'John' 'Doe'}}",

"age": "{{$randomInt 18 65}}",

"price": "{{$randomPrice 10 100 2 '$'}}"

}

This lets you control:

Length of random strings
Name-based email generation
Integer ranges
Price ranges and formatting

You get flexibility without writing extra logic

Real-world use cases

Dynamic variables shine in real workflows:

Signup flows: create unique users for each test run without database cleanup.
OTP/timestamp tests: generate valid, time-based payloads for authentication flows.
Load testing: feed randomized inputs to surface edge-case bugs.
CI/CD pipelines: run reliable, repeatable tests that don’t rely on pre-seeded data.
Mocking servers: return realistic, variable responses for front-end dev work.

These turn brittle tests into reliable checks and speed up development feedback loops.

How Lodash Can Simplify Your API Testing

kanishkrawatt — Wed, 19 Nov 2025 11:32:15 +0000

API testing can get messy fast. You deal with deeply nested JSON, inconsistent response structures, repetitive validations, and way too much boilerplate. Lodash cuts through all of that. And since Requestly exposes Lodash globally as _ inside your Script Tab, you can start using its utilities instantly, no importing or setup required.This article breaks down how Lodash actually makes API testing easier, with examples you can plug straight into your Requestly scripts.

Why Lodash Is a Game-Changer for API Testing

Most API testing involves tasks like:

Extracting values from deeply nested response objects
Filtering arrays
Checking for missing fields
Comparing expected vs actual data
Transforming inconsistent data
Creating small helpers on the fly

Doing all that with plain JavaScript works… but it’s verbose, error-prone, and annoying. Lodash gives you battle-tested helpers that simplify all of these into one-liners.

Using Lodash Inside Requestly Scripts

You don’t need to install or import anything. Lodash is already available globally as _ inside Requestly’s scripting environment.

console.log(_.toUpper('requestly')); // REQUESTLY

This means you can clean, inspect, validate, and transform data right where you're testing.

Practical Use Cases for API Testing

1. Check if a Field Exists

if (!_.has(responseBody, 'data.user.email')){ 
    console.log('❌ Missing email field'); 
}

2. Validate That Two Responses Match

const expected = { status: 'active', plan: 'premium' }; 
const actual = responseBody.profile; 
if (_.isEqual(expected, actual)) { 
    console.log('✔️ Profile matches expected structure'); 
}

3. Filter Arrays Cleanly

const activeUsers = _.filter(responseBody.users, u => u.active);
console.log('Active:', activeUsers);

4. Map Data for Assertions or Next Requests

const names = _.map(responseBody.users, u => u.name);
console.log('User names:', names);

5. Safely Get Deep Values

const role = _.get(responseBody, 'data.profile.role', 'unknown');
console.log('Role:', role);

6. Remove Unwanted Fields Before Passing Data Forward

const sanitized = _.omit(responseBody.user, ['password', 'token']);
console.log(sanitized);

Why Lodash Fits Perfectly With Requestly’s Script Runner

Lodash shines in scenarios like:

Writing assertions in response scripts
Cleaning API responses before chaining requests
Normalizing data for comparison
Generating structured logs
Avoiding brittle manual validations

If you run multi-step workflows or collection runs in Requestly, Lodash quickly becomes your go-to toolkit.

More Tools Available in Requestly

Requestly provides many other global utilities, third party plugins, and helpful libraries that you can use instantly inside scripts.
Learn more here: Import Packages into Your Scripts

Final Thoughts

Lodash doesn’t just simplify API testing, it removes friction entirely. Shorter scripts, clearer logic, fewer bugs. And since Requestly includes Lodash globally as _, you can use it instantly without any setup.

How to convert OpenAPI spec to Requestly API collection

Dinesh Thakur — Fri, 31 Oct 2025 06:26:33 +0000

If you already have an OpenAPI Specification (Swagger) for your API, you don’t need to recreate everything manually. With Requestly’s OpenAPI Importer, you can instantly convert your .yaml or .json spec file into a fully organized API collection, ready to explore, test, and document your APIs.

What Is an OpenAPI Specification?

The OpenAPI Specification (OAS) defines a standard, language-agnostic format for describing RESTful APIs. It describes endpoints, request methods, parameters, responses, authentication, and more — typically written in YAML or JSON.

OpenAPI specs are commonly used with tools like Swagger, Postman, and backend frameworks such as FastAPI, NestJS, or Spring Boot.

Requestly now makes it easy to bring these specs directly into your workspace — no extra conversions needed.

Why Import an OpenAPI Spec into Requestly?

Importing your OpenAPI spec into Requestly saves time and ensures consistency between your API documentation and test collections.

Here are the main benefits:

Instant API Setup — Automatically creates collections and requests for all your endpoints.
Structured Organization — Groups endpoints under tags and paths for easy navigation.
Accurate Data — Automatically includes request methods, headers, and body schemas from the spec.
Ready for Testing — Test endpoints right away with variables, environments, and scripts.
Seamless Migration — Bring your existing Swagger or Postman definitions into Requestly in seconds.

Supported Formats

The OpenAPI importer supports both:

.json — JSON format specs (commonly exported from Swagger or code generators).
.yaml / .yml — YAML format specs (commonly used in backend frameworks).

How to Import an OpenAPI Spec in Requestly

Follow these simple steps:

Open the API Client Go to your API Client workspace in Requestly. Make sure you’re in the workspace where you want to import your API collection.

Import Your OpenAPI File Click Import → OpenAPI and select your .yaml or .json file.

Preview Before Import Requestly will show a preview of what will be imported — including: – The collections that will be created – The environments and variables that will be set up Review the preview and confirm to complete the import.

Requestly builds your collection
- Each path in your OpenAPI file becomes an individual request.
- Requests are grouped under collections named after your API or service.
- Requestly automatically fills in the method, URL, headers, and body (if defined in the spec).

Wrapping Up

Importing your OpenAPI spec into Requestly is the fastest way to set up your API collection — no manual work, no missed endpoints, and no inconsistencies.

Whether you’re migrating from Swagger, Postman, or a backend framework, Requestly helps you centralize your API development, testing, and collaboration in one place.

👉 Try it now: Import your OpenAPI file in Requestly

How to Simulate Real User Journeys With Collection Runner

kanishkrawatt — Wed, 29 Oct 2025 11:05:21 +0000

In the world of API development and testing, it’s not enough to verify that each endpoint works in isolation. Real users don’t just hit one endpoint, they follow multi-step flows like signing up, logging in, updating data, and retrieving records. To truly validate your product, you need to test how these flows perform from end to end.

That’s where Requesty’s Collection Runner comes in.

Why Simulate User Journeys?

Most critical bugs don’t come from individual endpoints, they come from the interactions between them. A successful login that returns an invalid token, or a profile update that fails silently, can ruin the user experience and go unnoticed if tests don’t mimic real behavior.

Simulating real user flows helps you:

Validate business logic and data dependencies
Detect regressions that break chained functionality
Catch errors caused by state mismanagement or inconsistent environments
Build confidence that your product works as users expect

Requesty: A Collection Runner Built for End-to-End Testing

Requesty’s Collection Runner allows you to create and execute sequences of API requests with full support for:

Chained workflows
Dynamic variable passing
Pre-request scripting and test assertions
Environment switching

Here’s how to build and simulate a real-world user journey using it effectively.

Example Flow

New User Sign-Up → Login → Profile Setup → Data Fetch

This user journey includes:

Creating a new user via POST /register
Logging in using POST /auth/login to retrieve a JWT token
Setting profile data using PATCH /profile
Fetching user dashboard data via GET /dashboard

Step 1: Create the Flow as a Collection

In Requesty, collections are simply ordered groups of API requests.

Add each step listed above as a separate request in your collection.

Step 2: Link Data Between Steps

Use variable chaining to pass values dynamically between requests. For example:

Capture the userId and token from the login response
Inject them into headers or URLs in the following steps

// Example test script in /auth/login to extract token and user ID

// Parse the JSON response from the login request
let response = rq.response.json();

// Store the authentication token in the environment
rq.environment.set("auth_token", response.token);

// Store the user ID in the environment
rq.environment.set("user_id", response.user.id);

In the next request (such as PATCH /profile), include the authorization header as shown below:

Authorization: Bearer {{auth_token}}

Test Assertions and Validation

Each step in your API flow can include automated assertions to verify that responses meet expectations. These checks can include:

Status codes (e.g., 200, 201, 400)
JSON schema compliance
Business rules such as "email_verified": true

Assertions ensure your APIs behave correctly under real-world conditions and that regressions or logic errors are caught early.

Run Against Different Environments

Requesty supports environment switching, allowing you to execute the same collection across development, staging, and production without changing base URLs or tokens manually.

This ensures consistency across environments and helps uncover environment-specific issues.

Monitor and Share End-to-End Runs

After running your collection, you can:

Review pass/fail status for each request
Track response times and identify slow endpoints
Export or share detailed results with your team

This makes it easier for QA teams, product managers, and DevOps engineers to monitor system health and collaborate on fixing issues efficiently.

Real-World Use Cases

E-commerce: Add item → Checkout → Payment → Receipt
SaaS Onboarding: Create organization → Invite user → Accept invite → Create workspace
Fintech: Register → KYC → Deposit funds → View balance

Testing endpoints in isolation doesn’t reflect how users actually interact with your product.

Simulating complete workflows ensures that your system functions correctly across every step of the user journey.

Final Thoughts

End-to-end workflows are where your users truly operate.

To guarantee a reliable experience, you must validate the entire process, not just individual API calls.

Requesty’s Collection Runner simplifies this by combining automation, flexibility, and detailed reporting to help you detect issues before they impact users.

Ready to simulate your first user journey?

Try Requesty Collection Runner today.

Best Ways to Use Collection Runners for API Workflows

kanishkrawatt — Wed, 29 Oct 2025 10:49:41 +0000

Collection runners are one of the most underrated tools in API testing and automation. Whether you’re a developer debugging endpoints or a QA engineer automating tests, a collection runner can save hours of repetitive work and dramatically improve coverage.

Here are some powerful ways to leverage a collection runner to automate, validate, and scale your API workflows.

1. End-to-End Workflow Testing

End-to-end testing involves running a series of API requests that simulate an entire user workflow from start to finish.

Example: A user journey from account signup, profile setup, and adding items to a cart, to completing a purchase.

Scenario: Instead of sending each API request manually, chain them in a collection runner. Variables like user IDs or session tokens flow between requests automatically, simulating real-world behavior and uncovering potential issues in the full workflow.

2. Data-Driven Testing

Data-driven testing uses external files, like CSV or JSON, to test multiple input combinations automatically.

Example: Testing login functionality for different user roles and permissions using a CSV containing usernames, passwords, and roles.

Scenario: Run the collection once to validate dozens of combinations. This helps identify edge cases, such as invalid credentials or restricted access, without repeating manual testing.

3. Performance Smoke Testing

Performance smoke testing checks how APIs respond under repeated or high-frequency requests to spot slowdowns or errors.

Example: Sending the same API request 100 times in a row to measure response times.

Scenario: Quickly determine if any recent code changes caused response degradation or errors. While not a full load test, it’s perfect for lightweight checks after updates.

4. Continuous Integration (CI) Testing

Automating API tests as part of the development pipeline ensures that every code commit maintains API stability.

Example: Running automated tests in Jenkins or GitHub Actions every time new code is pushed.

Scenario: A developer updates a payment endpoint. The collection runner executes pre-configured tests to ensure all flows still work before merging, preventing broken releases.

5. Environment-Specific Testing

Testing the same collection against different environments — be it development, staging, or production — without modifying requests.

Example: Using environment variables for API base URLs and credentials to switch between staging and production.

Scenario: Run the same workflow in multiple environments to validate consistency and catch environment-specific issues.

6. Post-Deployment Sanity Checks

Quick validation of critical endpoints after a new release to ensure the system is functional.

Example: Checking login, health checks, and payment flows immediately after deployment.

Scenario: A new release goes live. A collection runner executes a small set of essential tests to catch any issues before users are affected.

7. Scheduled API Monitoring

Running collections at regular intervals to monitor uptime and API health over time.

Example: Scheduling a collection to run every hour and send alerts if any endpoint fails.

Scenario: Ensure key endpoints remain operational and catch downtime or errors before they impact users.

Final Thoughts

Collection runners transform repetitive API tasks into automated, repeatable workflows. By combining end-to-end testing, data-driven scenarios, environment management, and automated reporting, they make API testing smarter, faster, and more reliable.

Hacktoberfest 2025 Requestly: Build with us this October

Dinesh Thakur — Mon, 06 Oct 2025 12:39:30 +0000

Hacktoberfest is here—and we’d love your help on Requestly, our open-source API Client + HTTP toolkit. First PR or fiftieth, we’ll guide you to ship something meaningful, learn along the way, and earn rewards.

What’s Hacktoberfest? (20 seconds)

A month-long open-source celebration every October. Contribute accepted pull/merge requests (and/or no-code contributions), learn from the community, meet folks, and snag rewards. This year, Requestly is taking part in Hacktoberfest.

How It Works (Quick Overview)

Every contribution—whether it’s a pull request, a blog post, or a social share—earns you points. The more impactful your contribution, the higher the points. At the end of Hacktoberfest (after Oct 31), we’ll tally up all contributions and announce the winners in the second week of November.

We announce Top Contributors of the week on linkedin! Keep an eye out on the leaderboard:

👉 Leaderboard

Join Our Community on Discord

Our Discord server is the main place to connect, ask questions, and get updates in real time.

👉 Join the Requestly Discord

Once inside, grab the Hacktoberfest-Requestly role and jump into the #requestly-hacktoberfest channel to chat with the team, find issues, or get guidance on your first PR.

How to Start (super simple)

Code & Product

Visit the repo → Requestly GitHub Repo
Star & fork the repo(s)
Pick any issue labeled Hacktoberfest
Raise a PR with a clear description + a quick screen recording (Loom or similar).
Share your work on social media for bonus points (see scoring).
Track your points on our public leaderboard (updated weekly) (add link).

We review fast and kindly—new contributors are very welcome.

Points:

UI change or “good first issue” — 25 pts
Medium/Senior issue — 50 pts

API Collections (for other projects)

Requestly’s API Client supports local workspaces—keep API collections in a local folder inside any project, merge it and your API collection is available on github

Refer to this case study: Upscayl Case Study

Quick steps

Clone the target project’s repo. (any open source project apart from Requestly)
In Requestly API Client, create a Local Workspace and point it to a folder inside the cloned repo.
Create a Collection named [{Tool name}] API Collections (e.g., Stripe API Collections).
Raise a PR to add the collection.
If the parent project accepts your PR, you get extra points.

Note: The parent project must have ≥ 200 stars.

Points

PR raised — 25 pts
Merged into parent repo — 125 pts

No-Code Contributions

Try Requestly (Desktop App or Chrome Extension) and explore features.
Write a blog/article/tutorial about your learnings or a use case (personal site / DEV.to / Medium) — 35 pts
Social Promotion (Be authentic and use multiple platforms): When you share on social media, don’t just copy and paste content. Add your own thoughts, insights, or experiences so your post feels genuine and offers something valuable to your audience.
- First platform (LinkedIn or X) — 10 pts
- Each additional platform (Threads, YouTube Short, Reddit, DEV.to cross-post) — +5 pts each, cap +15 per post
- Duplicate posts without new value count once
Impact bump (stackable):
- > 1,000 impressions — +10 pts
- > 30 likes — +10 pts
- > 5 reshares — +10 pts

We’ll spotlight the #1 contributor each week on LinkedIn.

How to Submit Your Work

We track PRs on GitHub, but we also award points for learnings shared publicly.

All code contributions will be tracked directly on GitHub.

You don’t need to fill any form — we’ll automatically review merged PRs.
🗣️ All non-code contributors (like blog posts, tutorials, API collections, or social shares) should comment under the relevant sub-issue in our main Hacktoberfest issue:

👉 Hacktoberfest 2025 × Requestly

Once your comment is added, our team will review it and award points based on the scoring system listed above.

The issue and its sub-issues will lock on Nov 1, 12:00 AM IST, after which we’ll tally all scores and announce winners.

Rewards 🎁

Bronze (≥ 100 pts) — Digital certificate + LinkedIn shout-out
Silver (≥ 175 pts) — ₹500 Amazon gift card + Bronze perks
Gold (≥ 275 pts) — Swag Kit + ₹2000 Amazon gift card
Hall of Fame — Top 5 overall get a dedicated blog shout-out
Grand Winner (#1, ≥ 400 pts) — Landing page spotlight + Swag Kit + ₹5000 Amazon gift card

Shipping note: Swag/gifts are India-only.

Timeline (Oct 6–31, 2025)

All October: Contribute PRs, comment on issues, ask questions, publish posts, share on social.
When accepted: We’ll merge and label Hacktoberfest-accepted.
Weekly: Top Contributor of the Week → LinkedIn.
After Oct 31: We verify points and ship rewards.

Winners announced: After 12:00 AM, Nov 1, 2025 (IST).

We’ll lock the Google Form and tally final points.

New to Open Source? Start Here

Look for a good first issue—we’ll add plenty for first-timers.
Try our API Client and create an API collection for an open-source project (see the Upscayl case study).
Not a coder (yet)? Blogs, tutorials, and docs about your learnings all count.

Share a short LinkedIn/X post—those points add up quickly.

Your First PR: Quick Checklist

Before you start

Comment on the issue to get assigned.
Ask scope/clarification questions on the thread.
Start only after assignment.

When you open the PR

Title: feat|fix: concise summary
Description (template):
- Context: What/why (issue link)
- Approach: How you solved it
- Testing: Steps + expected behavior
- Screens: Before/after or a 60–90s Loom

After you open the PR

Be responsive to review comments.

What We Review For (fast & friendly)

Screen recording (fastest way to verify)
Clarity (description & screenshots)
Scope (one change per PR)
Quality (lint/tests pass; no spam or generated noise)

Hacktoberfest only counts accepted contributions. Spammy PRs are disqualified across the program. We follow the official anti-spam guidelines.

FAQ

How many PRs do I need for rewards?
No fixed number—it’s points-based. Both code and no-code contributions count.

Do no-code contributions count?
Yes. Try Requestly, write about your learning, and share on social for extra points.

Can I do both Code and no-code contributions?
Yes! Make as many contributions as you can to earn points

What makes a repo “participating”?
Look for the hacktoberfest topic on the repository.

Are my social media posts accepted by default?
No. Posts must share genuine learnings. Duplicate/low-value posts won’t earn points.

Do you ship gifts internationally?
No. Rewards shipping is India-only.

Ready? Let’s Build Together

Visit our GitHub repo
Pick an issue, raise your PR, and share your work.
Stuck? Comment on the issue thread—we’ll help scope the work or suggest a beginner-friendly alternative.

Happy Contributing!

Rethinking API Workspaces for microservice architecture

Dinesh Thakur — Thu, 25 Sep 2025 12:18:47 +0000

In modern development, services rarely live in one giant codebase. Instead, applications are split into multiple microservices — each with its own repo, APIs, and logic.

Testing these APIs is just as important as writing the code, but here’s the problem:

Every service usually has its own API requests and environments.
Teams often manage these in separate workspaces.
Developers who need to test flows across multiple services end up juggling between workspaces.

This slows down debugging and makes collaboration harder.

Requestly’s Multi-Workspace View solves this by letting you keep API collections and environments inside each service’s source code and then combine them as needed.

Keeping API Collections Close to the Code

Instead of having a single central workspace for everything, each team can store its own Requestly workspace (collections + environments) alongside the service it belongs to.

For example:

📁 service-a
 ├─ 📁 src
 ├─ 📁 tests
 └─ 📁 requestly-workspace   # Contains API collections + environments

📁 service-b
 ├─ 📁 src
 └─ 📁 requestly-workspace

📁 service-c
 ├─ 📁 src
 └─ 📁 requestly-workspace

This approach has some big advantages:

Version-controlled: Workspaces live in Git, just like your code.
Scoped: Each service has only the API requests relevant to it.
Discoverable: Any new developer can clone the repo and instantly access the APIs for that service.

Mixing Services When You Need Them

Here’s where Multi-Workspace View comes in.

Say you’re working on a checkout flow that touches:

Service A (Auth)
Service D (Orders)

Instead of merging their API requests into one messy workspace, you can simply:

Clone both repos (service A and D).
Open Requestly.
Load the two local workspaces in Multi-Workspace View.

Now you have both sets of requests + environments available side by side. You can:

Call Auth APIs from service A.
Call Order APIs from service D.
Debug the full flow — without ever switching workspaces or duplicating requests.

This scales beautifully when teams maintain multiple repos but need to collaborate on larger workflows.

Benefits of This Approach

Close to source: Workspaces live where APIs are implemented.
Reproducible setups: New team members don’t need to hunt for API docs — they get the collections with the code.
Mix & match flexibility: Developers can load exactly the services they need (A + D, B + C, etc.) without clutter.
Cross-team collaboration: Workspaces can be versioned, reviewed, and shared just like code changes.

Getting Started with Multi-Workspace View

Step 1: Open Requestly and navigate to the API tab from the sidebar.

Step 2: In the top-right corner, click on your current workspace name to open the Workspace Selector dropdown.

Step 3: Check the boxes next to the local workspaces you want to load together.

Step 4: Your chosen workspaces will appear grouped in the selector.

Note: Multi-Workspace View currently works with local workspaces only.

Final Thoughts

Microservices encourage modularity in code — and your API testing setup should reflect that too. By keeping Requestly workspaces next to the service code and using Multi-Workspace View, you get the best of both worlds:

Organized, version-controlled API collections per service.
The flexibility to test across multiple services in one view.

This approach makes API testing more maintainable, collaborative, and aligned with how modern teams ship software.

Sharing Variables Across Workspaces in Requestly

Dinesh Thakur — Tue, 16 Sep 2025 07:53:04 +0000

When you’re working on different projects at once, it can be tricky to keep track of things like secret keys, user IDs, or special links. You might have workspaces for each project. But what if you need to use the same piece of information, like a login key, across all of them?

Copying and pasting is slow and you might make mistakes. Requestly has a cool feature to help with this, called Runtime Variables.

What Are Runtime Variables?

Think of Runtime Variables as temporary sticky notes for your work in Requestly. They are simple bits of information that you can create and use anywhere.

They have two key features:

They Work Everywhere: If you create a runtime variable once you can use it in any workspace right away.
You Can Save Them for Later: Usually, these “sticky notes” disappear when you close Requestly. But you can toggle them to “Persist”, which saves them for the next time you open the app.

How do runtime variables work?

The most important thing to know is that Runtime Variables have the highest precendence in Requestly. If another variable has the same name, the Runtime Variable will always be used instead.

Here’s how Requestly decides which variable to use, from most powerful to least powerful:

Runtime Variables
Environment Variables (Info for a specific setup, like “Testing”)
Collection Variables (Info for a specific folder of requests)
Global Variables (General info)

For example: Let’s say you have a saved link called {{baseURL}} that points to a test website. But for a quick test, you need to use a server running on your own computer.

Instead of changing your saved settings, you can just create a Runtime Variable also named {{baseURL}} and point it to your local server (like http://localhost:3000). Now, all your workspaces will use your local server. When you’re done, just delete the runtime variable, and everything goes back to normal!

How to Use Them

Getting started is easy.

In Requestly, go to the API Client. And click on Runtime Variables tab on the side.

In the variables table, click + Add More and enter the variable details:
- Key – The variable name (e.g., session_id).
- Value – The value you want to store.
- Type – Select from String, Number, Boolean, or Secret.
- Persistent – Toggle whether the variable should be saved across app restarts.
  - Yes → Keeps its value after restarting the app.
  - No → Clears itself automatically on restart.

That’s it! Now you can use {{session_id}} in any request in any of your workspace.

Some Cool Ways to Use Them

Login Keys: When you get a login key that expires soon, save it as a runtime variable. All your workspaces can now use that same key.
Testing with Different Users: Need to see how your app works for a specific person? Just create a runtime variable like {{userID}} and pop in their ID to test across all your workspaces.
Switching Features On/Off: If you’re testing a new feature that can be turned on or off with a special value, put that value in a runtime variable. This makes it super easy to flip the feature on or off everywhere at once.
Using Multiple Workspaces at Once: Requestly lets you open several workspaces side-by-side. Runtime Variables are perfect for this! If you update a variable like {{userID}}, the change happens everywhere instantly. This is super helpful for testing how different parts of your app work together at the same time.
Using Multiple Workspaces at Once: Requestly lets you open several workspaces side-by-side. Runtime Variables are perfect for this! If you update a variable like {{userID}}, the change happens everywhere instantly. This is super helpful for testing how different parts of your app work together at the same time.

I Used Every API Client So You Don’t Have To

Ronak Kadhi — Mon, 08 Sep 2025 07:23:54 +0000

I tested Postman, Insomnia, Bruno, and Requestly head-to-head across real-world scenarios. By the end of this post, you’ll know exactly which one fits your workflow and your team’s size.

Each of these tools comes with trade-offs that only surface when you least expect them: right in the middle of critical development work.

These tools are constantly shipping new features, so if you haven’t revisited your setup recently, you might be missing out on significant improvements.

For context, I’m Jan Hesters, CTO of ReactSquad. I manage a team of over 20 frontend and full-stack developers who work with complex REST and GraphQL APIs

every single day. I spent weeks putting these tools through real-world scenarios, so you don’t have to. Here’s what I found.

What I Tested

To ensure a fair comparison, I used the following scenarios across all four tools:

Basic CRUD requests against ReactSquad’s Express starter app (GET, POST, PUT, and DELETE). I evaluated the ease of creating requests, reading responses, and inspecting headers.
Authentication flows: Basic Auth, OAuth tokens, and API keys. Some clients handle token management automatically, while others require manual configuration
Advanced features such as request chaining, environment variables, custom scripts, and API mocking. I explored how each tool enables data reuse between requests and test automation.
Collaboration and storage: Whether collections are stored locally or in the cloud, security implications, and how easy it is to share them with teammates.
Performance: startup time, memory footprint, and stability under heavy responses. I recorded approximate RAM usage on my laptop (32 GB RAM, Apple M1 Pro with macOS) and noted any crashes or freezes (spoiler: none). With those criteria in mind, here’s a tool‑by‑tool rundown.

Bruno

Bruno is a fully offline, open-source API client built around a plain-text markup language called Bru. Collections are stored as individual files in your project directory, making them easy to version with Git. There’s no login required, no cloud dependency, and no vendor lock-in.

Getting started

After launching, Bruno greets you with a minimal interface: a tree view of your Bru files on the left and request/response panes on the right. Creating a request is as simple as adding a .bru file with YAML-like syntax. Because everything is stored locally, you can use standard Git commands to commit changes and collaborate through pull requests ( commit, push, pull, etc.). There’s no login prompt and no telemetry collection.

When it comes to security, Bruno is offline-first and account-free by design. Collections are plain text .bru files in your project, so versioning, access control, and auditability ride on your existing Git workflows rather than a vendor cloud.

Bruno ships a first-class CLI for running any collection in your CI/CD runners. Run bru run against a collection, folder, or single request.

Unique features

File-based storage – requests and collections are plain text .bru files saved directly in a folder. This means you can diff, merge, and review API requests likeany other code. Bruno even provides a VS Code extension for syntax highlighting.
Offline by design – the application doesn’t require an internet connection to start or run. All API calls originate from your machine, not through a proprietary proxy.
Security & Privacy – fully offline by design. No telemetry, no cloud accounts. All data stays on your machine, which can be a non-negotiable requirement for teams in high-security environments.
Unlimited collections and runs – there are no artificial limits on how many times you can execute a collection. Paid plans simply add convenience features such as a GUI for Git operations and secret management

Trade-offs

Because Bruno is relatively young, it lacks some advanced features. There’s no built-in mocking or request interception, and collaboration happens entirely through Git. Scripts are written in JavaScript but are limited compared with Postman’s sandbox. If you’re comfortable with Git and want full control over your API definitions, though, Bruno is a joy to use.

Postman

Postman is the established leader in this space and bills itself as a full API development platform. The feature list is enormous: a visual client for REST/GraphQL/SOAP requests, mocked endpoints, monitoring, API documentation, and even AI agents. The free plan supports up to three users and 25 collection runs per month and includes the core API client and a visual workflow editor called Flows. More advanced plans add unlimited seat counts, mock server quotas, private API networks, and role-based access control.

Installation and first impressions

Postman offers both a desktop app and a web client. I installed the desktop version and was immediately prompted to sign up. While you can skip account creation and use the lightweight API Client locally, you’ll need an account for workspaces, sync, mocks, monitors, and collaboration. Once inside, the interface feels like an IDE: tabs, sidebars, and pop-up modals compete for attention. Importing a collection from a JSON file is straightforward, and the built-in code generation feature can export your requests to cURL or various languages. Postman’s Postbot assistant (AI) can generate tests and documentation, but after 50 free actions per month you’ll
need to pay.

Postman takes a cloud-first but flexible approach to security, letting you work completely offline in its lightweight API Client so everything stays local until you sign in. Secrets can also remain on device via Postman Vault, which does not sync. If you opt into the cloud, data is encrypted in transit (TLS) and at rest (AES-256-GCM), and Enterprise plans add BYOK so encryption keys are customer managed.

If you need headless runs, Postman’s Newman CLI lets you execute any Postman collection from the terminal and wire it into CI easily. Typical flow: newman run collection.json -e env.json, or fetch the latest collection via the Postman API and run it in your pipeline. Newman exits with proper status codes, supports rich reporters (JUnit, HTML), and advanced flags for timeouts, SSL, and data files. Postman also offers a separate Postman CLI if that fits your team better

Pros

Comprehensive feature set – supports REST, GraphQL, SOAP, WebSockets, and more; includes mocks, monitors, and an AI assistant.
Collaboration – workspaces, commenting, and real-time sync make it easy for teams to share collections and track changes.
Scripting and automation – powerful JavaScript sandbox for pre-request and post-response scripts. And the Newman CLI-runner allows you to integrate your API tests into your CI/CD pipelines.
IDE integration – Official VS Code extension to send requests and manage collections from your editor (sign-in required).

Cons

Resource heavy – the desktop app consumed ~450 MB of RAM during my tests and felt sluggish with large collections; the web version isn’t much lighter.
Cloud-first design – collections and secrets are stored in Postman’s servers by default. Offline usage is limited and some features require constant connectivity.
Pricing – the free plan is restrictive (3 users, 25 collection runs/month). Hitting these limits and needing more advanced features quickly pushes you into more expensive paid tiers.

Requestly

When you open Requestly for the first time, it’s different from the other API clients. That’s because Requestly nudges you into its mocking capabilities.

If Postman/Insomnia/Bruno feel like “API clients first, everything else second,” Requestly flips that script: it leads with interception and mocking. On first run you’re gently pushed to connect an app (e.g., a browser, an app running on your computer, or even an external device) because the core idea is to intercept & change traffic on the fly to unblock frontend work.

Getting started

You’ve got to install both the browser extension and the desktop app of Requestly.

The Browser extension (Chrome/Firefox/Edge) allows you to intercept and modify requests right in the browser. You can tweak headers, swap hosts, override response bodies, or stub GraphQL responses while you code. No local proxy setup needed.
The Desktop app (Mac/Windows) is an open-source local proxy that can intercept traffic from any desktop app (or even mobile simulators) and can be set to system-wide mode. You use it to intercept non-browser traffic to debug APIs from native apps, emulators, or multiple browsers at once. Requestly starts local and only goes cloud when you ask it to. Local Workspaces keep rules, collections, and environments on your device; Team Workspaces add sync for collaboration. The desktop proxy and much of the tooling are open source, and the company publishes SOC 2 Type II compliance for teams that need formal assurances.

If you want to integrate Requestly into your CI/CD pipeline, you have to understand that Requestly is rule-driven rather than a traditional “collection runner.” This means you can automate it in two useful ways:

The Public API to create, update, and fetch rules and mocks before tests run in CI.
The Automation SDK Automation SDK (@requestly/rq-automation) to load the extension and apply your rules inside headless browsers with Playwright, Selenium, or Puppeteer.

You can also route terminal and system traffic through the desktop proxy when you need interception outside the browser.

What stood out in my tests

Client-side & system-wide mocking: Override responses in the browser via the extension or at the OS level via the desktop proxy. You can set custom status codes, headers, delays, and entire JSON bodies, and even bulk-generate mocks from recorded sessions. GraphQL is first-class: you can modify queries/mutations or mock them outright.
A real API client, not just an interceptor: Organize Collections, manage Environments, import cURL, and use pre-request/post-response scripts. Team workspaces exist if you want cloud collaboration; otherwise you can stay fully local.
Open-core model: The desktop app is open source on GitHub; you can use it locally and opt into paid cloud features only if you need them.
Performance (anecdotal): On my machine (M1 Pro, 32 GB RAM), the desktop app hovered around ~67 MB during basic rule testing.
UX: Subjective, but to me the UI feels the most modern and coherent, especially when jumping between rules, API Client, and history.

Where it shines

Frontend dev speed: Toggle rules to simulate backend states, switch hosts between prod/stage/local, inject experimental scripts, or throttle/delay calls to test spinners and error paths — without touching your app code.
GraphQL teams: Need to reshape a query or force an error response? It’s a two-minute rule instead of a backend change.
Beyond the browser: Debug traffic from Electron apps, native apps, or simulators via the desktop proxy.

Trade-offs

Not an API-lifecycle suite: You get a capable API Client plus elite interception/mocking, but not the deep API-design/governance layers (private API networks, audit trails, etc.) that Postman markets to large enterprises. (That said, Requestly d o e s offer team workspaces and cloud sync if you want them.)
Rule-centric mental model: If your muscle memory is “open client → send request,” Requestly’s rule first workflow can feel unusual for pure API exploration— until you start leaning on mocks and rewrites to speed up frontend work.

Insomnia

Insomnia has long been the lean, developer-friendly alternative to Postman. In the past, it has been my go-to tool for API testing because I like that it only does a few things, but it does them well. After being acquired by Kong, it now offers a polished desktop client that supports REST, GraphQL, gRPC, and WebSockets. It remains fully open source with optional cloud sync and Git integration for team sharing.

Installation and setup

Insomnia’s installer is roughly 140 MB, and no account is required for local use. I downloaded the build from their site and was up and running in seconds. The UI is clean—a left pane for your requests and environments, a middle pane for request details, and tabs for response, headers, and timeline. Adding an environment variable is as simple as typing {{base_url}} and defining it in the environment editor. Insomnia also supports multi-protocol requests; creating a WebSocket request uses the same workflow as a REST call.

Insomnia leans into user choice for data storage: pick “Local Vault” to keep everything on device, “Git Sync” to version in your own repo, or “Cloud Sync” with end-to-end encryption. With E2EE, encryption happens client-side and the passphrase is never stored server-side, so losing it means the encrypted data cannot be recovered.

If you want to integrate Insomnia into your CI/CD pipeline, Insomnia’s Inso CLI can run collections and unit tests headlessly, lints OpenAPI, and generates docs.

Strengths

Plugin ecosystem – Insomnia exposes a robust plugin API with hooks and template tags. You can install community plugins from the Insomnia Plugin Hub or write your own to add custom authentication, pre-request logic, or even theme the interface.
Git/Cloud storage – choose to store your collections locally, sync with Insomnia’s cloud or connect to a Git repository. This flexibility is ideal for teams with strict security requirements.

Limitations

Collaboration – while you can sync with Git or their cloud, there’s no built-in commenting or role-based access control. Large organizations may require more
governance than Insomnia provides.
Enterprise features – API design and documentation are available, but advanced analytics, role management, and single sign-on require an enterprise plan.

Comparison

We have made a comprehensive comparion table here
When you make a decision, you should consider the total cost of ownership (TCO). Seats are only part of the bill. Budget for run quotas and add-ons (collection runs, AI, mocks and monitors), CI minutes and artifact storage, and any compliance needs like EU residency or BYOK that can push you into enterprise tiers. Local-first saves on vendor overages but shifts cost to process: backups for local workspaces, managing E2EE passphrases, and a bit of glue code to keep rule-driven mocks stable in CI. In short, hosted convenience costs money each month, Git-first costs you maintenance time, so do the math on runs per day, suite length, and mock volume for your team

Final thoughts

I’m looking into these tools from the perspective of a manager for frontend and fullstack React developers. The truth is, when it comes to just sending API requests
and storing collections, they all do more or less the same and they all do it well.

But, after extensive testing, my choice for the ReactSquad team is Requestly. This decision, however, is highly dependent on our specific constraints and priorities.

The deciding factor was solving our most significant development bottleneck around API clients: waiting on the backend solving our most significant development bottleneck around API clients: waiting on the backend. Requestly’s seamless interception and mocking capabilities directly address this pain point in a way no other tool does as effectively. The ability for a developer to unblock themselves by modifying an in- flight API response – without code changes or complex setup – is a massive productivity booster.

In general, I wasn’t fully convinced by any of the CLI tools these apps provide. That might just be because of how our teams usually work with APIs. Most of our
projects already use testing frameworks like Playwright or Vitest with Supertest, and we run API tests as part of our E2E or integration test suites.

That said, Requestly’s Chrome extension works inside Playwright, which means you could skip setting up MSW and mock requests using Requestly if you don’t need it
elsewhere. And, if your project doesn’t have a proper testing setup in place, using something like Postman’s Newman or Requestly’s public API can be a quick and
practical alternative.

Here is my recommended decision tree to help you choose:

If your team already has a preference. listen to your team. In the end, your team has to be happy with your choice.
If you are an open-source purist, choose Bruno. It offers a 100% offline, Git-native workflow, and prioritizes performance and simplicity above a sprawling feature set.
Choose Requestly if you are a frontend or full-stack developer, and your biggest frustration is being blocked by API availability. If you need powerful, easy-to-use mocking and interception integrated with a solid API client, Requestly is in a class of its own.
And finally, if you need all of the enterprise features of Postman, like a single, all-in-one platform for API design, governance, monitoring, and collaboration, and you are comfortable with a cloud-first, account-mandatory model, choose Postman.

How to Intercept & Modify GraphQL Requests with Requestly

Dinesh Thakur — Mon, 14 Jul 2025 07:58:32 +0000

GraphQL APIs have become the go-to choice for modern frontend applications. Their flexible querying system allows clients to request precisely the data they need—nothing more, nothing less. But this same flexibility often makes debugging, testing, and experimenting harder.

What if you could intercept a GraphQL request and tweak its variables, override certain fields, or simulate different input values—without touching a line of code?

That’s where Requestly comes in.

In this guide, you’ll learn how to intercept and modify outgoing GraphQL requests using Requestly’s Modify Request Body rule. Whether you’re testing pagination logic, simulating another user, or altering request payloads for debugging, Requestly makes it incredibly easy.

Why GraphQL Request Interception Is Different

GraphQL sends all operations (queries and mutations) to a single endpoint, typically as a POST request. Unlike REST, where URL and query parameters define the resource, GraphQL includes the operation and variables in the request body, making traditional URL-based interception ineffective.

That means:

You can’t just filter by URL—you must filter by operationName or payload keys
Any meaningful changes require modifying the body JSON, not headers or URL params

Requestly handles this gracefully with dedicated support for GraphQL operation filtering and request body rewriting.

Example: Limit Product list in Requestly Playground by Modifying a GraphQL Variable

In this example, we’ll demonstrate how to intercept a GraphQL request in the Requestly Playground and modify one of the query variables to control the number of products fetched.

Step 1: Understand the Playground Setup

First, open the Requestly Playground. Choose any GraphQL demo available. If you inspect the Network tab in DevTools, you’ll notice a request sent to the GraphQL server with a payload like this:

This is a POST request that contains the operationName, variables, and the query itself. In our case, we want to modify the first variable, which controls how many products are fetched.

Step 2: Create a Modify Request Body Rule

To intercept and update the request:

Open HTTP Rules

Navigate to the HTTP Rules section in the web or desktop app.
Create a New Rule

Click on “+ New Rule” and select Modify Request Body.
Configure Resource Type

Choose “GraphQL API” as the Resource Type.
Enter your source condition

In the Source Condition, enter the domain of the GraphQL API:
Set GraphQL Operation Filter

In the GraphQL Operation (Request Payload Filter) section:
- Enter Key as operationName.
- Set Value as Products (which is the operation used in this demo)

Customize Request

Now, let’s override the GraphQL request with modified values. You can either write dynamic JavaScript or directly paste the static modified payload.

For this demo, we’ll use a static replacement where we set first: 3 to limit the results.

{
    "operationName": "Products",
    "variables": {
        "searchJoin": "AND",
        "first": 3,
        "language": "en",
        "search": "type.slug:grocery;status:publish"
    },
    "query": "query Products($search: String, $date_range: String, $orderBy: String, $sortedBy: String, $language: String, $searchJoin: String = \"AND\", $first: Int = 15, $page: Int) {\n  products(\n    search: $search\n    date_range: $date_range\n    sortedBy: $sortedBy\n    orderBy: $orderBy\n    language: $language\n    searchJoin: $searchJoin\n    first: $first\n    page: $page\n  ) {\n    data {\n      ...ProductParts\n      author {\n        name\n        slug\n        id\n        __typename\n      }\n      __typename\n    }\n    paginatorInfo {\n      ...PaginatorParts\n      __typename\n    }\n    __typename\n  }\n}\n\nfragment ProductParts on Product {\n  id\n  name\n  slug\n  type {\n    id\n    name\n    slug\n    settings {\n      productCard\n      __typename\n    }\n    __typename\n  }\n  product_type\n  price\n  sale_price\n  min_price\n  max_price\n  quantity\n  unit\n  sku\n  is_digital\n  is_external\n  ratings\n  image {\n    id\n    thumbnail\n    original\n    __typename\n  }\n  video {\n    url\n    __typename\n  }\n  tags {\n    id\n    name\n    slug\n    __typename\n  }\n  status\n  external_product_url\n  external_product_button_text\n  in_flash_sale\n  __typename\n}\n\nfragment PaginatorParts on PaginatorInfo {\n  count\n  currentPage\n  firstItem\n  hasMorePages\n  lastItem\n  lastPage\n  perPage\n  total\n  __typename\n}"
}

We’ve updated "first": 3, this will instruct the server to return only 3 products.

Save and Activate

Click Save, then toggle the rule ON to activate it.

Refresh the Playground

Now return to the Requestly Playground and reload the demo. You should see only 3 products loaded instead of the default 20:

Advanced Targeting with GraphQL Operation Filters

Requestly allows you to precisely target GraphQL operations by their name, even when multiple queries share the same endpoint.

When defining your rule:

Use operationName to specify the GraphQL query/mutation you want to modify.
You can also add conditional checks for specific variable values (e.g., country: 'US').

This is especially useful when:

Multiple operations use the same endpoint
You only want to modify one particular request out of many

Conclusion

Modifying GraphQL requests in-flight can dramatically improve how you develop and test modern web apps. Requestly’s Modify Request Body rule gives you full control over the GraphQL payload—without touching the source code or backend services.

Whether you’re debugging, prototyping, or experimenting—Requestly empowers you to own your client-side workflows end-to-end.