Skip to main content

Guide

Test APIs locally, without a required account

APIWeave is local-first: install the desktop app and build, run, and store workflows with no account at all. This page is specific about what that covers — including the one thing a “stays local” claim usually gets wrong.

Download APIWeave

No sign-up, no backend, no telemetry

What stays put

Three things that never need a server

The desktop app is complete on its own. A Cloud account adds collaboration; it is not a prerequisite for anything on this page.

Your workflows and environments

Workflows, projects, environments, and run history live in a single SQLite database under your OS user data directory. There is no hosted backend for them to live in instead.

Your secret values

Secret values are sealed with a Libsodium sealed box against the install's public key before the write leaves the renderer. The store is write-only: no UI, IPC handler, or MCP tool can read a value back.

Your requests and responses

Requests are sent from your machine over your network, against the environment you selected. Response bodies and run history are never uploaded to APIWeave Cloud.

Be precise

What does leave your machine

“Local” should mean something checkable, so here is the whole of it.

The API you are testing
A request goes to the host you configured, over your network. That is the point of the tool. Whatever you put in that request — a header, a body field, a resolved secret — reaches that service.
An update check to GitHub Releases
The app checks shortly after launch and every six hours while the window stays open. Set Settings → Updates to Manual only and only the Check for updates button reaches the network.
Cloud sync, if you turn it on
Optional and structural: workspace, project, and workflow structure, environment names and secret references, plus membership, roles, and revisions. Values and payloads are not part of it.

The distinction that matters

A secret value is never uploaded to APIWeave Cloud — not even for sync, where only the reference travels and the API rejects a payload carrying secret material. It is still sent to the API under test when a workflow uses it, because that is what the request is for. The value is sealed at rest, decrypted only in the runtime path, and scrubbed by the masking layer before the run is written to history, so it does not appear in your local run history either.

Secrets

A store that is write-only by construction

A credential you cannot read back is a credential that cannot leak through the app.

{{secrets.NAME}} resolves through a fixed local chain:

  1. the selected environment's secret store
  2. the workspace secret store

First scope that declares the key wins. There is no third scope.

Write path:
  renderer encrypts with a Libsodium sealed box
    -> ciphertext travels over IPC
      -> main process stores it verbatim

Read path:
  none. The Secrets page shows name, scope, key id, and timestamps.

Secrets live at one of two scopes: the workspace, visible to any workflow in it on this machine, or an environment, visible to workflows that select it. The scope is fixed at creation.

Inheritance between environments carries plain variables only. An environment that extends another does not gain access to its base's secrets — the scope chain above is unaffected.

The store is local to one machine. Copy keyfile.json from the user data directory alongside the database and the secrets follow; lose it and the store cannot be opened. A synced workflow resolves secret references against the store of whichever machine runs it.

Network surface

Nothing listens until you ask it to

The app opens no port by default. The one network surface it can offer is a loopback bridge for a local AI agent.

Transport:  Streamable HTTP on a loopback port
Endpoint:   /mcp   on 127.0.0.1
Auth:       Authorization: Bearer <per-install token>
Port:       47271 preferred; a free loopback port if that one is taken
Default:    off. Nothing listens until you enable the bridge.
  • It binds to a loopback address only — never a LAN or public address — and every request needs the per-install token.
  • Browser-originated requests are accepted only from a loopback origin, which protects the endpoint against DNS rebinding.
  • The tool surface is an explicit whitelist over the same IPC registry the app uses, and it is deliberately smaller than the renderer's.
  • Secret tools expose names, scopes, and resolution metadata only. They never return a value and cannot mutate a secret.
  • Run tools return metadata, not payloads. The one exception, runs_getNodeResult, still passes every read through the same secret redaction.

If you add Cloud

Collaboration without moving execution

Cloud is a control plane for structure. It never builds, runs, or hosts a workflow.

What syncs

  • Workspace, project, and workflow structure
  • Environment names and secret references
  • Membership, roles, and revisions

What stays here

  • Secret values
  • Run history and response bodies
  • The requests you send to your systems under test

Cloud never runs your tests and stores no run history. When two machines change the same record it raises a conflict for you to resolve field by field rather than overwriting either side.

Local is the default. If you would rather verify it in code, the desktop app and this control plane are both public.