Studio is a desktop API client. It tests any HTTP API, not only ours, and it holds the catalog so you can pick an endpoint, fill in parameters and send without writing a request or leaving the app.
Download APIVerve Studio — Windows, macOS and Linux, free, and no account required to use it.
It is in active development and the feature list below is what ships today, not what is planned. Issues and requests go to GitHub.
What it does
Build and send requests. All the HTTP methods, the body types you would expect, headers and query parameters, with the response formatted and syntax-highlighted. GraphQL requests have their own editor alongside REST.
Authenticate however the API wants. API key, Bearer token, Basic auth and OAuth 2.0 are
built in, so you are not hand-assembling an Authorization header to test someone else's API.
Browse the catalog. Every APIVerve endpoint is listed in the app with its parameters, so testing one is a matter of selecting it rather than copying a URL from a reference page.
Organise into collections and workspaces. Group related requests, keep separate workspaces for separate projects.
Use environment variables. Define {{base_url}} and {{api_key}} once per environment and
switch between dev, staging and production without editing every request.
Keep a history. Every request you send is recorded and re-openable, which is usually how you recover the one that worked.
Generate code. Turn any request into a snippet — including cURL — for pasting into a terminal or a codebase.
Where your data lives
On your machine by default. Collections, history and environments are stored locally. Nothing is uploaded and no account is needed.
Cloud sync is opt-in. Signing in with your APIVerve account enables syncing collections across devices. Not signing in costs you nothing but the sync.
This is the practical reason to prefer Studio over a hosted client for anything sensitive: an environment holding a production key stays on the machine unless you deliberately ask for it not to. That said, it is still a file on a laptop — see security, and use a sub-key for local testing rather than the primary key.
Studio, the playground, or Postman
Three tools that overlap, and the honest split is:
The playground is in the dashboard, needs nothing installed, and already knows who you are. Best for one quick call to see what an endpoint returns.
Studio is for a session rather than a call: several requests, saved, re-run, with environments and history. It also tests APIs that are not ours, which the playground does not.
The Postman collection is for teams already living in Postman, and for the Collection Runner. Also the right answer if you need to share a set of requests with people who will not install anything new.
Use whichever is already open. None of them changes what the API does.
Installing
| Platform | What you get |
|---|---|
| Windows | A portable executable, or an MSIX package — x64 and ARM64 |
| macOS | A .dmg — Intel and Apple Silicon |
| Linux | An AppImage — x64 and ARM64 |
The Windows portable build needs no installation: download and run.
The macOS build is not notarised yet, so Gatekeeper blocks it on first open. Right-click the app and choose Open to run it anyway, or allow it under System Settings → Privacy & Security. A normal double-click will keep refusing.
Linux AppImages need the executable bit set before they will run:
chmod +x APIVerve-Studio-*.AppImage
./APIVerve-Studio-*.AppImageWhat it does not do
Worth stating so you do not go looking:
- No WebSocket or SOAP testing. Studio is an HTTP client. For those, use a tool built for them.
- No GraphQL schema introspection. You can write and send GraphQL requests; the editor will not fetch the schema and autocomplete against it.
- No plugin system.
Credits
Requests Studio sends to APIVerve endpoints are ordinary API calls and cost exactly what they would from anywhere else — one call at the endpoint's rate, counted against the same rate limit. Requests to other APIs cost nothing, because they never touch us.
A history full of re-sends adds up faster than it feels like it should, so if you are iterating on a request against an expensive endpoint, check analytics afterwards.
Next
Quickstart is the fastest first call, Postman is the same catalog in a collection, and SDKs are the step after a request works.