Skip to main content
APIWeave
Download

Docs

Build your first API test workflow

A workflow is the test: nodes wired in order, each one building on the response before it. This walkthrough builds one against a public endpoint, runs it, and reads the result — in about five minutes, with no account and no backend.

Download APIWeave

Windows · macOS · Linux — no account required

Walkthrough

Five steps to a green run

Everything here happens in the desktop app. Nothing is hosted, and nothing needs installing beyond the app itself.

  1. Create the workflow

    Open the workflows list from the sidebar and click New Workflow. A Start node is placed for you.

  2. Add the request

    Drag an HTTP Request node from the Add Nodes panel onto the canvas. Set the method to GET and the URL to https://httpbin.org/get — a public endpoint that always answers 200.

  3. Assert the contract

    Drag an Assertion node on and connect the request's output to its input. Add one rule: source status, operator equals, expected value 200. Both nodes must pass.

  4. Pick an environment and run

    Choose an environment in the canvas toolbar — create one on the Environments page if the selector is empty — then press Run. Both nodes turn green within a second or two.

  5. Read the result

    Click either node for its request, response, and assertion result. The workflow autosaved about 700ms after your last edit, so it is already on disk.

The graph you just built
[ Start ] -> [ HTTP Request: GET /get ] -> [ Assertion ] -> [ End ]

What just happened

  • The canvas wrote your workflow to a local SQLite database about 700ms after the last edit.
  • Run sent a typed IPC call to the main process, which walked the graph from Start and streamed progress back to the canvas.
  • The green check on the Assertion node means the status rule passed: the response code equaled 200, which is what that endpoint returns.

Reuse a response

Send a value from one request into the next

This is the loop the whole tool is built around: log in, capture the token it returns, and prove the next call works with it.

Login → token → authenticated call
HTTP Request: POST /login  ->  200 OK { "access_token": "abc123" }

Extractor:
  name = token
  path = response.body.access_token

Later node:
  Authorization: Bearer {{variables.token}}

An extractor pulls a value out of a response and stores it as a workflow variable. Add one from the response tree — hover a row and choose Save as variable — or write the path by hand under Settings → Store response as variables → Add manually.

Paths use dot notation with [index] for arrays and always start with response.:

  • response.statusCode
  • response.headers.content-type
  • response.body.id
  • response.body.user.id
  • response.body.items[0].id
  • response.body.errors[0].message

The value is available to every later node in the same run as {{variables.token}}, and the Variables panel shows what each extractor wrote.

The four placeholder namespaces

Placeholder namespaces, what each reads, and an example
SyntaxReadsExample
{{env.NAME}}The environment selected for the run{{env.BASE_URL}}/users
{{variables.NAME}}A workflow variable, set by hand or written by an extractor{{variables.token}}
{{prev.response.body.field}}The immediately previous node's response{{prev.response.body.items[0].id}}
{{secrets.NAME}}The local encrypted secret store, through the scope chainAuthorization: Bearer {{secrets.API_KEY}}

Placeholders resolve in a fixed order: functions first, then secrets, then environment values, workflow variables, and the previous node result. A placeholder that cannot be resolved is left in the field as literal text rather than blocking the run, and the run records it as an unresolved reference.

Secrets

Add a key the workflow can reference, not store

Once the happy path runs, the next thing most workflows need is a credential. APIWeave keeps the value sealed and lets the workflow reference it by name.

  1. Open Settings → Secrets and choose Add secret.
  2. Pick the workspace or environment scope and give the key a name, such as HTTPBIN_AUTH.
  3. Submit. The renderer encrypts the value with a Libsodium sealed box against the install's public key before the write leaves it.
  4. The page then shows metadata only: name, scope, key id, and timestamps. Never the value or the ciphertext.
  5. In a request header, type {{ to open autocomplete and pick secrets.HTTPBIN_AUTH rather than typing the whole path.
  6. Run it. The header reaches the service with the decrypted value, and the masking layer scrubs it before the run is written to history.

A secret value is write-only at every layer. The main process never accepts a plaintext secret on a write path, no IPC channel or MCP tool can read a stored value back, and the plaintext never appears in the canvas, run history, or an exported bundle. When a workflow uses a secret, the value is sent to the API under test as part of that request — from your machine, never through APIWeave Cloud.

Next

Where to go when the first workflow runs

Three guides cover the next step most people take.

Chain requests together

Pass a token or ID from one response into the next request.

Read the guide

Import an OpenAPI or Swagger spec

Turn an API definition into ready-to-run request templates.

Read the guide

Test locally without an account

How execution, secrets, and storage stay on your machine.

Read the guide

The desktop repository carries the full documentation set: concepts, every node type, environments, MCP, and reference tables.

Full documentationDownload