Reqable: an issue tracker for a closed-source API debugging client

What reqable/reqable-app actually is: a tracker, not a codebase

Open the repository and you find no application source. The top level holds README files in nine languages, a .github directory, a .gitignore and an arts folder of screenshots. The README states the position plainly: "Reqable is not an open-source project. This repository is used solely for issue tracking, feature requests, and user feedback." That sentence should reset expectations before anything else on this page matters.

The product itself is a desktop and mobile client for two jobs that usually need two programs. The first is capturing HTTP(S) traffic through a man-in-the-middle proxy so you can read what an app or a browser actually sends. The second is composing and sending requests yourself: HTTP, WebSocket and SSE today, with gRPC marked "coming soon" in the README. The intended user is a developer or QA engineer who moves between those two activities many times a day and is tired of exporting a capture into a separate client.

Because the repository is a tracker, the usual signals you would use to judge an open source project do not apply. There is no commit history to read, no dependency tree to audit, no build you can reproduce. What you can judge is the release cadence visible on the repository: 3.2.23 on 2026-08-10, 3.2.22 two days earlier, 3.2.21 the day before that. The last push to the repository was on 2026-08-10. That tells you issues are being read and builds are shipping. It tells you nothing about what is inside the binary.

MITM capture on desktop, a local VPN on mobile

The README describes the capture mechanism without hedging: Reqable "employs a classic MITM (Man-in-the-Middle) strategy to intercept HTTP(S) traffic." The transport differs by platform. On desktop, Reqable configures a system-level proxy, so traffic from applications that respect the system proxy setting flows through it. On mobile, it uses a local VPN interface instead, because a system proxy is not something a normal Android or iOS app can set for other apps.

Once traffic is intercepted, the debugging primitives listed in the README are request replay, inline editing, breakpoints, URL rewriting and custom scripting. Those are the operations that separate a capture viewer from a debugging tool. Replay resends a captured request, often after you change a header or a body field. Breakpoints pause a request or response so you can alter it before it continues. Rewrite rules apply those alterations automatically by pattern.

The mobile edition is described as keeping "feature parity with the desktop version," with one explicit carve-out the README makes in a note: "Breakpoint, rewrite, and scripting features are currently unavailable on mobile platforms due to platform-level security policies." That is a real gap, not a footnote. If your workflow depends on pausing a request mid-flight, you need the desktop build. The mobile app can still forward traffic to a desktop peer, paired by scanning a QR code, so the desktop does the manipulation while the phone supplies the traffic.

The protocol coverage in the topics list is broad: HTTP, HTTP/2, HTTP/3 and QUIC. The README does not explain how each is handled beyond naming them, so treat the topic list as a scope statement rather than a description of implementation.

Install Reqable and capture your first request

Reqable ships as a signed installer or package per platform, not as a source build. The README's installation table is the authority here, and it lists formats and minimum versions for each target. On macOS the README gives a Homebrew command, which is the shortest path:

brew install reqable

That installs the universal macOS build, which the README says requires macOS 11.0 or later. On Windows there is an exe installer (the README calls it "recommended") and a portable zip, both for x86_64 and both supporting Windows 7 and above. On Linux there is a deb package and an AppImage for x86_64, and the README notes a dependency: GTK 3.0. Android builds are on Google Play or as apk files for arm64-v8a, armeabi-v7a and x86_64, requiring Android 5.0 or later. iOS is on the App Store and requires iOS 13.0 or later.

After installation, the first real task is getting traffic to appear. On desktop, Reqable sets the system proxy, so the sequence is: launch the app, start capture, then make a request from the application you want to inspect. For HTTPS you will need Reqable's certificate trusted on the machine or device whose traffic you are reading. The README does not walk through certificate installation in the repository text; it points to the documentation at reqable.com/en-US/docs/introduction, and the related searches show that "Reqable certificate" is a phrase people look for, so expect that step to be documented on the site rather than in the README.

For mobile capture, the README's route is the local VPN. Enable it in the app, install and trust the certificate on the device, then either inspect on the phone directly or pair with a desktop peer by scanning a QR code so the traffic is forwarded for deeper work. The README does not document rollback of the proxy or VPN settings, so plan to turn capture off manually when you are done.

The MCP server is the one part you can read

Reqable includes an MCP (Model Context Protocol) server, which lets an AI assistant such as Claude or GitHub Copilot talk to the application directly. The README frames the use cases as "API debugging, traffic inspection, rule authoring, and automated testing." In practice that means an assistant can drive Reqable's operations through the protocol instead of you clicking through the interface.

The detail worth noticing is the licensing split. The README says the application is not open source, then adds that "the MCP server implementation is fully open source" and links to a separate repository, reqable/reqable-mcp-server. So the integration surface is auditable even though the core is not. If your review process requires reading code before you connect a tool to an AI assistant, this is the part you can actually read, and it is the part that will be handling whatever the assistant asks Reqable to do.

That split also tells you how the project thinks about extensibility: keep the client closed, open the adapter. It is a common arrangement, and it is a reasonable one for a commercial desktop product. It does mean the trust boundary sits at the MCP server, not inside the application.

Flutter and C++ instead of an embedded browser

Reqable is built with Flutter and C++, and the README makes a point of what it avoids: "deliberately avoiding an embedded browser runtime." That choice is the origin of most of the numbers the README quotes. Millisecond-level cold start, an installation footprint under 100 MB, and typical memory consumption under 300 MB during active use.

Those figures come from the vendor, and the README is explicit about the machine behind the benchmarks: an Apple MacBook Pro with the M5 chip. It also states that "on lower-specification hardware, Reqable's performance delta is even more pronounced," which is a claim about relative advantage rather than an absolute measurement. Read the numbers as vendor benchmarks on named hardware, not as independent results.

The architectural argument is the interesting part. Electron-based API clients carry a browser engine, which is a large attack surface for a tool whose entire job is to decrypt and hold your traffic. Skipping that runtime is a security argument as much as a performance one, and the README presents it that way. It is also a constraint: Flutter and C++ mean the UI is not something a user can restyle with a plugin, and the plugin ecosystem that surrounds browser-based tools does not carry over.

Where Reqable is the wrong tool

The closed-source nature is the first limit, and it is not a philosophical one. If your organisation requires that every tool touching production credentials or customer traffic be buildable from source, Reqable fails that test at the first question. The repository cannot help you; it holds README files and screenshots.

Mobile is the second limit, and the README states it directly rather than burying it. Breakpoints, rewrite rules and scripting are unavailable on Android and iOS because of platform security policies. A workflow built on intercepting and mutating requests in flight simply does not exist on a phone here. You can capture on mobile and forward to desktop, but the phone alone will not do it.

The third limit is scope. Reqable is a client and a proxy, not a load generator, not a service mesh observability platform, and not a mock server. The README lists no load-testing or synthetic-monitoring capability. If your question is "how does this endpoint behave under 5,000 concurrent connections," this is not the instrument. Similarly, gRPC is listed as "coming soon," so a gRPC-first team should check the current documentation before assuming coverage.

Finally, the pricing structure is a limit for some teams. The README says most features are free with no trial period, that the Community edition covers most individual developers, and that power users and teams may benefit from Premium. It does not enumerate which features sit behind Premium. That list lives on the website, and you should read it before standardising a team on the Community tier.

How it compares with mitmproxy and Charles

The closest open source alternative is mitmproxy. The difference is not features so much as form. mitmproxy is a Python program with a console interface, a web interface and a scripting API, and you run it wherever you like: your laptop, a container, a remote host. Its interception logic is code you can read and extend. Reqable is a packaged application with a graphical interface and a mobile client, and its interception logic is inside a binary. If you need to run the proxy on a server and script it, mitmproxy is the more natural fit. If you need a desktop app that a QA engineer can open and use without writing Python, Reqable is aimed squarely at that person.

Charles Proxy is the other reference point, and it is the tool Reqable most resembles in shape: commercial, graphical, cross-platform, MITM-based. The difference the README pushes is architectural, the absence of an embedded browser runtime, plus a mobile edition with feature parity and a built-in API client in the same window. Charles has a long history and a large body of documentation; Reqable is younger, with version 3.2.x releases appearing in August 2026. Neither the README nor the repository gives a migration path from either tool, so switching means re-creating your rewrite rules and collections by hand.

Maintenance, upgrades and what the licence does not tell you

The repository is not archived, and the last push was on 2026-08-10, the same day as the 3.2.23 release. Three releases landed in the four days before that. The issue tracker is clearly live. What the repository cannot show is the maintenance state of the application itself, because the application is not in the repository. Release cadence is the only maintenance signal available, and it is a proxy, not proof.

Upgrade cost is low on the surface. The macOS build updates through Homebrew, and the README's installation table implies the same download-and-install path for other platforms. The README does not document an auto-update mechanism, a rollback procedure, or a way to pin a specific version, so if a release breaks your capture setup, the recovery path is whatever the download page offers at that moment. That is worth testing on one machine before you roll a version across a team.

The licence is the larger unknown. The repository has no licence file, and the README states only that the project is not open source and that features are split between a free Community edition and a paid Premium tier. It does not reproduce the terms. The MCP server repository is described as fully open source, which is a separate licence from the application. If you need to know whether you may use Reqable in a commercial setting, how many seats Premium covers, or what happens to captured data, read the terms on reqable.com rather than inferring them from the GitHub repository. Nothing here is legal advice, and the repository does not contain the answer.

Editorial conclusion

Adopt Reqable if you want one application for both capturing HTTP(S) traffic and sending API requests, and you accept that the code is closed and the GitHub repository is a feedback channel rather than a source tree. Do not adopt it if your policy requires an auditable, self-hosted proxy you can rebuild from source, or if you need breakpoints, rewrite rules and scripting on Android or iOS, which the README says are unavailable there. Before committing, verify three things: that your target platform meets the stated floor (Windows 7+, macOS 11.0+, Android 5.0+, iOS 13.0+, or GTK 3.0 on Linux), that the licence terms of the Community and Premium tiers fit how your team will use it, and that you can install and trust the MITM certificate on the devices you intend to capture. The repository at github.com/reqable/reqable-app is where you file what breaks.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. reqable/reqable-app on GitHub