Chapar: a native API client for REST, gRPC, GraphQL and WebSocket

A GUI without a browser engine

Chapar is a fast, native API client for REST, gRPC, GraphQL and WebSocket, with a built-in proxy for inspecting the traffic of other apps. It is written in Go and draws its UI with Yoga, a GPU-rendered (WebGPU) UI toolkit, so it starts quickly, stays light, and runs the same on macOS, Linux and Windows without a browser engine.

That last clause is the whole positioning. The description calls it a local-first Postman alternative written in Go: no Electron, no account, no cloud. The alternative approach to the incumbent tools is not a better feature list, it is a different substrate. A browser engine costs startup time, memory and a large dependency surface, and Chapar replaces it with a Go UI toolkit that talks to the GPU directly.

The go.mod confirms the substrate. The module is github.com/chapar-rest/chapar built for go 1.26.2, and the direct dependencies are telling. There is github.com/mirzakhany/yoga v0.25.1 for the interface, google.golang.org/grpc and google.golang.org/protobuf for gRPC, github.com/coder/websocket for WebSocket, github.com/getkin/kin-openapi for OpenAPI import, github.com/jhump/protoreflect for proto files, and github.com/lqqyt2423/go-mitmproxy for the intercepting proxy.

So the four protocols are not four plugins bolted onto a UI. Each one is a real Go client library, and the proxy is a fork of a Go MITM proxy rather than a hand-rolled socket interceptor. The repository is licensed BSD-3-Clause, the homepage is chapar.rest, and the last push was on 2026-10-18 with v0.11.0 released the same day.

Your requests are YAML files in a workspace

The storage model is the part that will decide whether you like this tool.

Everything is stored as YAML files, so a workspace can live in git. That single line changes the nature of the tool compared with the incumbents, whose workspaces are opaque local databases or account-bound cloud documents. A YAML workspace is diffable, reviewable, mergeable, and greppable.

The organising objects are workspaces, collections and environments. Workspaces keep separate collections, requests and environments, and you switch between them from the title bar. Collections share headers, auth and notes with every request inside them. Environments hold variables you use as {{name}} anywhere in a request, and values you mark secret are encrypted with a key kept in the OS keychain.

The secret handling is worth noting for a local-first tool. The encryption key lives in the OS keychain through github.com/zalando/go-keyring, which is the right place for it, and it means the YAML file on disk is safe to commit even when it holds a token. The alternative, a key next to the file it protects, would have made the git-friendly storage model a liability.

The auth types are Basic, Bearer token and API key, and they can be set per request or inherited from the collection. The cookie jar is per environment, with cookies from responses stored and sent back automatically, and you can view, edit, add or clear them.

For a team that already keeps its request definitions in a repository, this is the model they would want anyway, and Chapar is one of the few clients where that is the default rather than a plugin.

The proxy is the part that goes beyond a request sender

Most API clients are for talking to services you own. Chapar also ships an intercepting proxy, and the capability list for it is more considered than you would expect from a first release.

You can capture traffic from apps, browsers and phones through a built-in HTTP(S) proxy and see each request and response side by side. You can filter by app or domain, by protocol and content type, or by search, pin what you care about and skip domains you do not want decrypted. Captured requests can be turned into something editable with Open in Chapar, and taken elsewhere with Copy as cURL and Export HAR.

The certificate story is handled for you. Chapar makes its own certificate authority, trusts it in one click on macOS, and checks every step. Phones get the certificate and instructions from http://chapar.mitm.

Two constraints on the proxy are stated in the readme and are worth respecting. Chapar never changes your system's proxy settings, and the proxy only runs while you have it started. That is a deliberate choice about blast radius. A tool that silently rewrites your system proxy is a tool that can break your machine's connectivity when it exits badly, and one that leaves a MITM certificate installed is a standing risk. The proxy here is a thing you start and stop.

The screenshot set confirms the flow: proxy, proxy setup, and the certificate setup steps, alongside the request views.

Test cases, pre and post request scripts, and running them in CI

The workflow features are where an API client becomes a testing tool, and Chapar covers this area more fully than the screenshot grid suggests.

Test cases send your requests in order, check their responses (status, headers, JSON paths, timing and more) and pass values from one step to the next, with setup, teardown and retries. You can run them in the app, or in CI with chapar-cli.

Pre and post-request actions are the more interesting mechanism. You can run another request first, extract values from the response body, headers or cookies into the environment, or write Python scripts with tests and logs. That last option is a scripting hook with a test harness attached, which is a stronger contract than a free-form script hook that silently swallows failures.

The response checks cover status, headers, JSON paths and timing, and the timeline view records DNS, connect, TLS, time to first byte and scripts for every request. The timeline is what you look at when a request is slow, and having it per request rather than in a separate tool is convenient.

The command palette, on Cmd+K or Ctrl+K, opens any request, collection or environment and runs any command. The editors have language-server completion and diagnostics, with Python out of the box and JSON, XML, Go, JavaScript and more configurable in Settings. A post-request script panel and a notification history are also in the screenshots.

For CI, the chapar-cli binary is built separately from the desktop app. The Makefile builds it with CGO_ENABLED=0 and -trimpath into dist/chapar-cli, and a release script archives it for every platform into dist/cli, so the CLI ships alongside the GUI rather than being a separate project you have to install.

The protocol coverage, read closely

It is worth reading the protocol list carefully, because the difference between a request sender and a real client is usually in the details.

For REST and HTTP, Chapar supports every method, query and path params, JSON, XML, text, form-data, URL-encoded and binary bodies, with syntax highlighting and formatting.

For gRPC, the support is server reflection or proto files, unary and server-streaming methods, metadata and trailers, TLS and client certificates, and a sample message for any method. The sample message per method is a real quality-of-life feature, since hand writing an empty protobuf request to discover the field names is a waste of an afternoon. The gap to notice is that the list says unary and server-streaming, which leaves client-streaming and bidirectional streaming unmentioned.

For GraphQL, the support is queries and variables, with the response data and errors split out. Splitting data from errors is the detail that matters, because a GraphQL response can carry both at once and a client that flattens them into one blob makes error handling worse than doing it by hand.

For WebSocket, you can connect, send text, JSON or binary messages and save them to resend, and watch everything that arrives in a filterable log, with subprotocols, pings, compression, headers and auth like HTTP requests.

MQTT is next on the list, which means it is not there yet, and the roadmap also lists tunneling to servers and Kubernetes clusters as pre-request actions.

Getting it, and the mock server you can try first

The distribution model is a GitHub release per platform rather than a package manager, and the project links the releases page from its getting started section. The release badge is configured to include prereleases, which tells you that prerelease builds are part of the workflow rather than an accident.

The better starting point, though, is the mock server. The screenshots use the Tokyo Night theme and the free Chapar mock server, at mocks.chapar.rest, which you can use to try every feature. That is a significant piece of restraint from a project that also ships a proxy: instead of asking you to point a traffic interceptor at your own services, it gives you a server that answers whatever you send it.

For the build from source, the Makefile is small and readable. The run target is go run., the test target is go test./..., and the lint target runs golangci-lint with the repository's own.golangci-lint.yaml configuration. There is a vendor target that calls./build/vendor.sh rather than go mod vendor, with a comment explaining why: it also restores the tree-sitter C sources that go mod vendor drops, which is a detail you only learn by having had a broken build.

The packaging goes through the yoga CLI, configured by yoga.toml, and the Makefile notes that make install_deps installs the version of the yoga CLI that go.mod builds the app with. The macOS packaging targets produce unsigned ad-hoc DMGs for local testing, and a separate signed target produces Developer ID signed, notarized and stapled DMGs, which needs an IDENTITY, an APPLE_ID, an APPLE_TEAM_ID and an APPLE_APP_SPECIFIC_PASSWORD or a notary keychain profile.

The.cursor directory are also in the tree, which is a reasonable sign of what a Go and WebGPU project looks like in practice.

Where Chapar is the wrong choice

There are clear boundaries, and the strongest one is the local-first decision itself.

The first is that there is no account and no cloud sync. Your requests, environments and cookies are plain files on your machine, and nothing is sent anywhere you did not ask for. That is the privacy and control argument, and it is genuinely valuable. It is also a single-user argument. There is no shared workspace, no team request library with permissions, no history synced between machines. If your team needs a common collection of requests that everyone can pull and contribute to, this tool does not have that shape, and the YAML layout does not by itself provide it, because a shared YAML directory is a convention rather than a feature.

The second is the protocol coverage, which we read above. gRPC streaming is partial, GraphQL supports queries and variables but the list does not mention mutations, and MQTT is on the roadmap rather than shipped. If your work is MQTT-heavy or depends on bidirectional gRPC, this is not the client for it.

The third is the WebGPU dependency. A GPU-rendered UI is what makes Chapar fast and light compared to an Electron app, and it is also a new dependency on the platform. On a machine with no usable GPU path, or on an operating system where WebGPU support is still catching up, the app's main selling point becomes its main risk.

The fourth is the pre-1.0 pace. The releases show v0.9.1 on 2026-10-02, v0.10.0 on 2026-10-14 and v0.11.0 on 2026-10-18, which is a very fast release cadence for a project at version zero. That is good for responsiveness and bad for stability guarantees, and it means you should expect your installed version to be behind within weeks.

And the fifth is the proxy. Interception tooling is genuinely useful for debugging other people's clients, and it is also the kind of feature that gets you into awkward conversations with the teams whose software you are inspecting. Chapar mitigates this by not touching system proxy settings and by only running when started, but the responsibility for what you point it at is yours.

Editorial conclusion

Adopt Chapar if you want a local first API client that keeps its workspaces in YAML, covers the four protocols you actually use, and gives you a proxy for reverse engineering other apps without shipping your traffic to anyone's server. Skip it if you need team-wide sync, a shared request library with a hosted component, or MQTT, which is still on the roadmap. Verify first that the protocol coverage you depend on is complete, in particular gRPC streaming, and that the release you download includes a chapar-cli build for your platform if you plan to run test cases in CI.

Frequently asked questions

Official sources

1. chapar-rest/chapar on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases