The API workbench
that sends from the metal.
REST, GraphQL and WebSocket in one workspace with environments, variables, post-response tests, a collection runner and a load generator. Requests leave from Rust, not the webview, so there is no CORS, no preflight, and redirects, TLS and proxies behave the way you set them.
Free · No account · Signed, self-updating builds
Everything the request touches, in one window.
Thirteen screens built on the Nocturne design system, with four accent palettes, a light mode, three densities, and perceptual OKLCH colour throughout.
↗REST
Params, headers, auth and body with response body, headers, cookies, a timeline, and TTFB plus total timing on every send.
◇GraphQL
Introspect into a browsable schema, edit variables, and read Apollo extensions.tracing when the server sends it.
⇄WebSocket
Connect, send, and watch a frame log with direction, size and close reasons. It is the one transport that runs in the webview.
{}Variables
{{var}} across URL, params, headers and body. Runtime → environment → collection → global precedence, with unresolved names shown in red before you send.
✓Tests
pm.test, pm.expect, pm.response and pm.*.set, plus matchSchema against schemas from your imported OpenAPI spec.
▶Runner
Sequential collection runs, N iterations or one per CSV row, captured variables carried between steps, and a failure table that points at the assertion.
∿Load
N virtual users on ramp, constant or spike shapes, with live one-second buckets, latency percentiles and the response-code mix.
↓Import
OpenAPI 3 and Swagger 2 (JSON and YAML), Postman v2.1, HAR and cURL, with example bodies and schema assertions generated on the way in.
▤Console & Docs
Every send from every screen logged with headers and timing; docs generated from the real wire request, with cURL, JS, Python and Go snippets.
Requests go out from Rust, not the browser.
Aperture is a Tauri 2 app. The send path is reqwest on the Rust side, which is
what removes the whole class of problems a browser-based client inherits.
- ✓No CORS, no preflight. You test the API, not the browser's opinion of it.
- ✓Redirects, TLS and proxies behave exactly the way the request is configured.
- ✓Pooled clients keyed by transport settings, so connection reuse and the cookie jar survive between sends.
- ✓Local by default. The workspace lives on your machine, and is repaired on load if an id no longer resolves.
Import a spec. Run the collection. Read the numbers.
The path from an OpenAPI file to a load profile is four screens, and the same variables and assertions follow you the whole way.
Not everything is built yet, and the app says so where it appears.
These show a real explanation in place of placeholder data, rather than pretending:
Download Aperture
One file, straight from the latest release. Every build self-updates from this repository, and every update is cryptographically signed and verified before it installs.
Not your platform?
Also available:
Windows .msi ·
Debian .deb ·
Fedora .rpm ·
all files and checksums
Builds are not code-signed or notarised yet, so first launch shows a warning.
macOS: right-click → Open → Open. Windows: More info → Run anyway.
Linux: chmod +x Aperture_*.AppImage.
The .deb and .rpm packages are owned by your package manager and do not self-update.