Features

AsyncAPI dispatches through every shipped wire

One asyncapi.yaml, five wire plugins. Each bindings: key the doc declares has a resolver that hands the call to the matching shipped plugin.

The AsyncAPI plugin doesn’t talk to brokers itself — it’s a discovery source that reads the contract and dispatches. Today every active binding maps to a real, shipped plugin: bindings.mqtt / mqtt5 to Kuestenlogik.Bowire.Protocol.Mqtt, bindings.kafka to Kuestenlogik.Bowire.Protocol.Kafka, bindings.amqp / amqp1 to Kuestenlogik.Bowire.Protocol.Amqp, bindings.ws to Kuestenlogik.Bowire.Protocol.WebSocket, and bindings.http through Bowire’s built-in HTTP client.

The benefit: an AsyncAPI doc travels as the contract surface (review it in PRs, version it in Git), but the runtime is whatever wire the broker speaks. Switch from Kafka to MQTT by editing the bindings: block; no Bowire side changes needed.

Read the AsyncAPI docs →

flowchart LR
    Doc[("asyncapi.yaml")]
    AAPI(["AsyncAPI plugin"])
    Res{"BindingResolver"}
    MQTT(["Protocol.Mqtt"])
    Kafka(["Protocol.Kafka"])
    AMQP(["Protocol.Amqp"])
    WS(["Protocol.WebSocket"])
    HTTP(["HTTP (built-in)"])
    NATS(["Protocol.Nats — follows"])

    Doc --> AAPI
    AAPI -->|"channels · operations · bindings"| Res
    Res -->|"bindings.mqtt / mqtt5"| MQTT
    Res -->|"bindings.kafka"| Kafka
    Res -->|"bindings.amqp / amqp1"| AMQP
    Res -->|"bindings.ws"| WS
    Res -->|"bindings.http"| HTTP
    Res -.->|"binding pending"| NATS
        

Every call pattern in one UI

Unary, server-stream, client-stream, duplex — plus REST verbs, GraphQL subscriptions, SignalR hubs, raw WebSocket frames, MQTT publishes. One UI, same muscle memory across all of them.

Streaming calls render into a Wireshark-style append-only list with per-frame detail. Duplex / client-stream open a persistent channel with a “send next message” composer on one side and incoming frames on the other. REST maps verbs onto the same invoke pane; GraphQL has a selection-set picker plus subscription follow-up via graphql-transport-ws.

Read the technical docs →

Form or raw JSON

Schema-driven form inputs for the common case, a full JSON editor when you need to tweak something unusual. Toggle with f.

The form view auto-generates controls from the discovered message shape: typed number inputs for int32, date pickers for google.protobuf.Timestamp, dropdowns for enums, nested cards for messages, repeated-field tables. Client-side validation flags missing required fields and type mismatches before a single byte hits the wire.

The JSON view is a full editor with syntax highlighting, bracket matching, and inline validation errors. State is preserved per method, so switching away and back never loses work.

Read the technical docs →

{
  // typed form mirrors this shape
  "city": "Berlin",
  "days": 7,
  "units": "celsius",
  "include_humidity": true,
  "filter": {
    "after": "2026-04-22T00:00Z"
  }
}

Bowire's own ops as MCP tools

bowire mcp serve exposes Bowire itself as an MCP server. The agent can chain discover → invoke → assert → switch env → replay the same way a human would in the workbench, just with more parallelism.

Primitives exposed: bowire.discover, bowire.invoke, bowire.subscribe, bowire.env.list, bowire.record.{list, start, stop, replay}, bowire.mock.{start, stop, list}, bowire.allowlist.show. Two transport modes: stdio for desktop clients (Claude Desktop, Cursor) and HTTP for remote agents (Copilot in CI, custom MCP runners).

Auth piggy-backs on whichever provider the workbench runs under, so the agent never sees a second credentials store. Tools are gated by the same allow-list the workbench uses — an agent can't reach a method a human couldn't.

Read the technical docs →

# Stdio — what Claude Desktop / Cursor want
$ bowire mcp serve --bind stdio

# HTTP for over-the-wire clients (Copilot, CI runners)
$ bowire mcp serve --bind http --port 5097

Replay recordings as a live mock server

bowire mock --recording session.bwr --port 5099 turns any captured recording into a live endpoint at the same shape as the original — so dev / test runs don't have to stand up the real backend.

The real backend is friction. The third-party API needs an OAuth flow + a paid subscription that burns credits on every test run. Your own service is a 12-container docker-compose with a 5-minute boot. The CI runner sits behind a corporate VPN that doesn't reach the upstream at all. A captured recording cuts all of that out of the loop — the fixture is the JSON file, drop it on a USB stick, drop it in a Git repo, hit replay.

Every protocol your recording captured replays through the same listener — REST verbs on the same paths, gRPC unary + server-streaming + bidi with the captured frames, WebSocket / SSE / SignalR / Socket.IO pushing the same sequence, MQTT publishes hitting the same topics, GraphQL subscriptions streaming the same events. Protocol semantics stay intact (status codes, frame timing, headers) instead of collapsing everything to a JSON stub.

Optional layers on top: hot-reload — rewriting the recording file refreshes the mock without restart; chaos injection — configurable latency / 5xx rate / dropped-frame ratio for resilience tests; schema-only mode (--from-spec openapi.yaml) — plausible responses from an OpenAPI / gRPC descriptor / GraphQL schema with no recording at all; capture-on-miss — unrecorded request transparently forwards to a fallback target, captures the response, serves it back next time.

Develop without the real backend — full writeup → Read the technical docs →

$ bowire mock \
    --recording session.bwr \
    --port 5099 --hot-reload

   # mock listening on 0.0.0.0:5099
   # 42 calls loaded across gRPC, REST, WebSocket

Schema-aware field-level fuzzer

bowire fuzz mutates one field at a time using the schema Bowire already knows. Knows not to throw SQL-injection at a latitude (lat) field; image.bytes gets magic-byte mutation, not XSS strings.

Schema-awareness is the differentiator: the fuzzer respects field types from the discovered schema (OpenAPI / proto / GraphQL / AsyncAPI). Image-byte fields get magic-byte / truncation / over-length mutation, integer fields get boundary / overflow / negative mutation, dates get format / range mutation, strings get the category-appropriate payloads.

Four payload categories ship out of the box: sqli, xss, pathtrav, cmdinj with curated wordlists. A baseline-diff oracle flags responses that look materially different from the baseline — status change, error-shape divergence, latency spike beyond N standard deviations. Findings reuse the same SARIF emitter as scan, so they drop into the same Code-Scanning surface.

Read the technical docs →

$ bowire fuzz \
    --target https://api.example.com \
    --template recordings/order.bwf \
    --field '$.customer.email' \
    --payloads sqli,xss --out fuzz.sarif

  payloads tried:  42
  baseline runs:    5
  divergent:        3   (status 500, latency >3σ)

Wireshark-style streaming view

An append-only message list on the left, a detail pane on the right — built for long-running duplex sessions, not a chat transcript.

Every incoming frame lands in a filterable table (substring, regex, or protocol-specific fields). Click one to see the full payload. Pin the latest to auto-follow, or pin a specific frame to keep the detail view stable while new messages scroll in. Works for gRPC server / client / duplex streams, SignalR real-time events, GraphQL subscriptions, WebSocket frames, SSE events, and MQTT subscribe streams — all with the same UI.

Read the technical docs →

Inline test assertions

Write Newman-style checks once, Bowire runs them after every successful response and shows a green / red badge inline.

Eleven comparison operators (eq, ne, gt, gte, lt, lte, contains, startsWith, endsWith, matches, type) target any value via response.path.to.value JSONPath. Assertions are stored per method, replay with every invocation, and can be exported into a recording so a flow becomes its own regression test.

For streaming responses, assertions run on the accumulated frames — “expect at least 3 frames of type TICK within 2 s” is one rule. No plugins, no pipeline, just a test that lives next to the request.

Read the technical docs →

response.status   eq   200        ✓
response.time     lt   500        ✓
body.user.id      eq   "42"       ✓
body.items[0]     type "object"   ✓