What sets Bowire apart
The cards on the home page give you the gist; this page gives you the substance.
Each section links to the technical documentation when you need the full picture.
Embedded — zero config
AddBowire() + MapBowire() in Program.cs, and Bowire ships next to your service. No companion process, no extra container, no shared database.
The plugin host hooks into the same DI container your app already builds. AddBowire() wires up the protocol registry, plugin loader, and middleware that exposes the workbench at /bowire. MapBowire() attaches the routes; everything else — discovery, invocation, recording — runs in-process against the live IServiceProvider.
Protocol prerequisites that you'd normally wire by hand are added automatically: gRPC plugins call AddGrpcReflection(), REST plugins read the existing IApiDescriptionGroupCollectionProvider, SignalR plugins enumerate mapped hubs via EndpointDataSource. No schema files, no manual endpoint registry, no parallel proto / yaml to keep in sync.
100% Local — no cloud
No accounts. No telemetry. No data leaves your machine. Bowire persists every credential, recording, and environment to your disk.
Workspace state lives in browser localStorage (per-origin, so dev/staging/prod each have their own). Recordings, plugins, and shared environments persist under ~/.bowire/ — a plain JSON tree on the file system that you can grep, diff, and check into a private repository if your team wants shared environments without paying for a sync service.
Outbound connections only happen when you tell Bowire to make one: clicking Execute hits the target API, that's it. No background pings, no opt-out telemetry, no remote feature flags. Enterprise security teams sign off on this in minutes — there's nothing to put in a Data Processing Agreement because there's no third party in the chain.
Read the technical docs →Open plugin architecture
Every protocol is a NuGet package implementing IBowireProtocol. Discovery, Invoke, Stream, Channel, Settings — one interface, infinite protocols.
Plugins ship as ordinary NuGet packages. Bowire loads them into per-package AssemblyLoadContexts so a plugin's transitive dependencies don't collide with the host or with each other — you can install the gRPC plugin (which pins one Google.Protobuf version), the GraphQL plugin (which pins another), and a third-party protocol (which pins a third), and they all coexist.
Authoring is six methods on one interface: DiscoverAsync, InvokeAsync, InvokeStreamAsync, OpenChannelAsync, the static plugin metadata, and the optional IBowireMockEmitter for mock replay. The same contract powers the official plugins (gRPC, REST, GraphQL, SignalR, …) and external ones (Storm, Kafka, DIS, UDP). End-users install via bowire plugin install <package-id>; air-gapped users via bowire plugin download + install --file.
Duplex channel manager
WebSocket, SignalR, MQTT, Socket.IO — every bidirectional protocol gets a persistent channel. Switch between methods and Bowire stashes the live socket; come back and it's still connected.
Most API tools either drop the socket the moment you click off the method (Postman) or only support one connection per workspace at a time (Insomnia). Bowire tracks each open channel as its own object: connect to a SignalR hub on one tab, an MQTT broker on another, a raw WebSocket on a third, and all three keep streaming. The sidebar shows a green dot per live channel; closing the workbench closes them, switching methods doesn't.
Per-channel state means request history, sent messages, and received frames all stay grouped per connection — even if you re-open the workbench tomorrow. For long-running streams (a SignalR hub with 30 minutes of accumulated frames) the Wireshark-style append-only viewer shows every event with timestamps and lets you scroll back through the whole history.
Read the technical docs →
Visual flow editor
Chain API calls into visual pipelines — branching conditions, loops, delays, variable forwarding. The kind of orchestration Postman locks behind a Teams subscription.
Each step is a node on a canvas: pick the service + method, set inputs (literal or ${response.path} from a previous step), choose what to do with the result. Branching nodes split on response value, status code, or timing; loop nodes iterate over an array or repeat until a condition fires; delay nodes pause for a fixed interval or until an external trigger. The whole flow is just JSON, version-controllable in the same repo as the rest of your workbench config.
Run the flow once interactively and Bowire shows the response from every step inline. Pin it to an environment and run it from CI via bowire test --flow — same orchestration, same output, no GUI needed.
Record and replay
Capture a real session once. Serve the exact same responses back as a live mock endpoint — same protocols, same payloads, same timing.
Click Record, run a sequence of calls, click Stop: now you have a JSON file with every request, response, status, header, and inter-call timing across every protocol you touched — gRPC streams next to SignalR hub invocations next to MQTT publishes next to REST hits, all on one timeline. Replay against another environment to spot drift, convert into test assertions for CI, export as HAR for teammates, or hand it to bowire mock to serve the recording back as a live multi-protocol mock.
Mocks aren't simulators, they're playback: every byte is what the real server actually sent. The mock server speaks every protocol the recording captured, so a test client sees exactly what production does — useful for unblocking frontend work before the backend ships, running offline contract tests, or sharing a realistic sandbox with a stakeholder without exposing the real environment.
Read the technical docs →
More than these six
The differentiators on this page are the headlines. The full feature list — auto-discovery, every call type, environments, auth helpers, performance graphs, response chaining, command palette, keyboard shortcuts — lives on the features page.
Different angle, same boat. Join the crew →