requestly/requestly Is a Community Hub, Not the API Client Source

What requestly/requestly Is, and What It Is Not

The repository description is explicit: it is a community hub for Requestly API Client, holding bugs, feature requests and the roadmap. The README repeats the point in its own words, stating that the API Client application is closed-source and that the community, bugs and roadmap live here in the open. So the code you can read in this repository is not the code that runs when you download the macOS, Windows or Linux build.

That distinction matters more than usual because the repository carries the project's own name. A developer who finds requestly/requestly, sees the AGPLv3 licence file and the topic list, and assumes the client is open source has made a reasonable but wrong inference. The licence section of the README separates the two: the repository is under GNU AGPLv3, while the API Client application is proprietary and governed by the terms at requestly.com/terms. The README also notes that third-party components retain their owners' licences, which is a standard carve-out and not a statement about the client's own code.

The README adds a historical note. This URL previously hosted the source for the open-source browser extension and web app, and that code now lives at requestly/interceptor. The old repository was kept as the community home rather than deleted. Anyone following an old link or an old tutorial will land here expecting extension source and find issue templates instead.

The Problem It Solves for Teams That Cannot Send Requests to a Vendor Cloud

The pitch in the README is data sovereignty first. It lists three storage modes: local, team sync, or self-hosted, with the claim that your data never leaves your control. For teams whose API collections contain internal hostnames, staging credentials or customer payloads, that is the deciding constraint. A hosted-only client forces a review of where request history and environment variables are stored, and for some organisations that review ends in a no.

The second claim is pricing predictability. The README states the product is free for up to 10 collaborators, with Team and Enterprise tiers adding governance, SSO, SAML, audit logs and on-prem deployment. It frames this against clients that meter usage or charge per add-on. Whether the 10-collaborator boundary is generous depends on team shape; a 12-person platform group hits it, a 6-person group does not.

The third claim is developer-first behaviour, described as hitting an endpoint and getting a response without bloat. That is a positioning statement rather than a measurable property, and the README offers no benchmark to support it. Treat it as intent, not evidence.

Git Sync, Local Workspaces and the Rest of the Feature List

The feature table is the most concrete part of the README. It lists a REST API playground for saving and re-running requests, pre-request and post-response scripts, import and export from cURL, Postman and OpenAPI, GraphQL support with schema introspection and auto-completion, Git Sync for keeping collections in a Git repository, and local workspaces that store data in local files with no cloud storage.

Git Sync is the feature that most changes how a team works. Collections become files in a repository, which means review happens through pull requests and history through commits. The README does not specify the file format, the branch strategy, or how merge conflicts inside a collection are presented in the client. Those are exactly the details that decide whether Git Sync is usable on a busy repository or painful on one, and they are not in the supplied material.

The same gap applies to scripts. Pre and post scripts are listed, but the README does not name the scripting API, the available globals, or whether scripts are sandboxed. Teams migrating from another client usually have a pile of existing test scripts, and the import path from that client is listed only for API contracts, not for scripts.

GraphQL and gRPC sit awkwardly in the material. GraphQL appears in the feature table with introspection and auto-completion. gRPC and WebSocket appear as repository topics, but the feature table does not describe either. A topic tag is not a feature description, so gRPC and WebSocket support should be confirmed in the documentation before you count on it.

Getting It Running: Downloads, Not Builds

There is no build step documented here, because the application source is not in this repository. Installation is a download from the links in the README's platform table: a macOS Apple Silicon build, a macOS Intel build, a Windows build and a Linux build, each behind a get.requestly.com redirect. The README also links the documentation at docs.requestly.com/api-client.

The README gives no system requirements, no installer format, no package-manager command and no configuration keys. It does not state where local workspace files are written on disk, which is the first thing to check if you plan to back them up or commit them. None of that can be confirmed from the supplied material, so it should be read from the documentation before rollout.

For contributors to this repository, the workflow is issue templates rather than code. There are separate templates for a bug report, a feature request and a question, and a projects board for the roadmap. The README also carries a routing rule: issues about the HTTP Interceptor extension and web app belong at requestly/interceptor, and misfiled issues will be redirected. That rule is worth reading before writing a report, because the two products share a name and a support surface.

Where This Repository Fails You as a Source of Truth

The main limitation is structural. A community hub cannot tell you how the client behaves internally. If you need to audit what the application sends over the network, or confirm that local workspaces never contact a server, the README's assurance is the only thing on offer here. There is no source to inspect, so verification depends on network observation or on the vendor's own documentation.

The licence split creates a second failure mode. AGPLv3 in this repository may lead a compliance reviewer to assume copyleft obligations attach to the client. The README says the opposite: the application is proprietary and not covered by that licence. Getting this backwards in either direction is a real risk, and the README is the only place in the supplied material where the boundary is drawn. This is a description of what the README states, not legal advice; a licence review is a separate exercise.

A third gap is release visibility. The repository's recent releases are changelog entries dated March 2026, with one per week in the supplied list. They are changelogs, not versioned binaries, so they do not tell you which client build corresponds to which entry. If you need to pin a version for a regulated environment, this repository does not appear to be the place to do it.

Finally, the self-hosting claim is underspecified. The README lists self-hosted deployment under Team and Enterprise tiers and mentions on-prem deployment in the same breath. It does not describe the deployment topology, the container images, or the database requirements. For a team whose whole reason for choosing Requestly is on-prem, that is the largest unanswered question in the material.

How It Differs from Postman and from Its Own Interceptor

The README positions the client against Postman directly, including a quoted user line about replacing it, and offers import from Postman collections. The difference in approach is where collections live. Postman's default model is a hosted workspace with cloud sync, with local storage as an option. Requestly's README inverts that: local workspaces are listed as a first-class feature with no cloud storage, and Git Sync makes a repository the collaboration surface instead of a vendor account. For a team already standardised on Git review, that is a genuine workflow difference rather than a marketing one.

The second comparison is inside the Requestly ecosystem and is easier to get wrong. The HTTP Interceptor is the open-source browser extension and web app, tracked at requestly/interceptor, with a separate desktop proxy at requestly/http-interceptor-desktop-app. It intercepts and modifies traffic from a browser or the system. The API Client designs, builds and tests API requests. They overlap in the sense that both touch HTTP, and they do not overlap in what you use them for. The README states the interceptor is not going away and that the API Client is where investment is going next, which is a useful signal about where roadmap attention sits.

There are further sibling projects listed: an MCP server at requestly/mcp, a web SDK, and Cypress, Selenium and Playwright integrations at requestly/requestly-automation. If your testing stack is Playwright or Cypress, that integrations repository is the relevant one, not this one.

Maintenance Cost and What the Licence Split Means in Practice

Because the application is closed source, upgrade cost is not something you control. You take the vendor's release cadence, and the changelog entries in this repository suggest a weekly rhythm in March 2026. There is no documented LTS branch, no self-managed patch path for the client, and no way to backport a fix. If a version breaks your workflow, the available moves are to file an issue here or roll back to an earlier download.

Git Sync shifts part of the maintenance burden onto you. Collections in a Git repository need a branching convention, a review rule for changes to shared environments, and a decision about whether secrets live in the repository at all. The README does not describe secret handling for Git Sync, and that is the first thing to settle before pointing it at a production collection.

The licence position is the item most likely to be misread. This repository is AGPLv3. The client is proprietary and covered by the product terms. Third-party components keep their own licences. If your organisation runs a licence scan across dependencies and finds this repository, the result will be AGPLv3, and someone will need to know that the scan is looking at a hub of issues and roadmaps rather than at client code. That is a documentation and process cost, not a legal conclusion, and it is worth resolving internally before procurement sees the two facts side by side.

Editorial conclusion

Adopt Requestly API Client if you want a Postman-style client with Git Sync, local workspaces and self-hosted deployment, and you accept that the application itself is closed source. Do not treat this repository as the product source or as evidence of an open development process; the README states the application is closed-source and that only the community, bugs and roadmap live here. Before committing a team, verify three things on the pricing page and in the docs: what the free tier's 10-collaborator limit counts, whether self-hosting is an Enterprise-tier feature only, and whether the GraphQL introspection and gRPC or WebSocket topics listed on the repo match the features your team needs. If you need to read or modify the client's source, this is the wrong project and requestly/interceptor is the wrong substitute, because that repository is the HTTP Interceptor, a different tool.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. requestly/requestly on GitHub