Every example is runnable

Drop Bowire next to your written guides. Readers click a method, edit the JSON, hit Send, see the real response — no curl-paste-and-pray loop.

The same workbench your engineers use as a debug tool, embedded into your docs site as a Try-It-Out widget. Auto-discovery means every example stays in sync with the running service; no separately-curated Swagger UI mirror to keep up to date.

Embed it next to the prose

Bowire mounts at a URL path; your docs reference it next to the relevant guide. Two lines in Program.cs, then iframe / link / direct mount — whatever fits your docs site.

Embedded mode is the natural fit: app.MapBowire() in your docs-host (or in the API service itself), and the workbench is reachable at /bowire next to the written guides. Readers click the method, fill the typed form (or hit f for raw JSON), Ctrl+Enter sends, response renders — no separate service to keep alive.

Standalone works too: ship a static docs site, link the relevant section at https://docs.example.com/bowire/?service=Orders&method=Create — deep-link state restores the picked method, the picked environment, and any inputs from the URL.

Embedded setup docs →

Copy out, run anywhere

A doc reader's goal isn't to keep clicking Send in the browser — it's to copy the working snippet into their own code. Every Bowire call exports as curl, grpcurl, or a typed C# / TypeScript snippet.

The exported snippet uses the exact values the reader just entered in the form — not a hand-curated example that drifts away from the live shape. Copy the snippet, paste into a script, run it. The auth picker (Basic / Bearer / JWT / OAuth2) becomes the appropriate header in the export; the gRPC metadata becomes a grpcurl --header; the GraphQL variables become a JSON body.

Typed exports (C# / TypeScript) include the strongly-typed message classes so the snippet drops into a real codebase as-is. No string-template gymnastics, no “adapt this example to your types” footnote.

Code-export docs →

sequenceDiagram
    autonumber
    participant Reader
    participant Bowire as Bowire (embedded)
    participant API
    participant Snippet as Code panel

    Reader->>Bowire: pick method · edit form
    Reader->>Bowire: Send (Ctrl+Enter)
    Bowire->>API: invoke
    API-->>Bowire: real response
    Bowire-->>Reader: render in response pane
    Bowire->>Snippet: regenerate curl · grpcurl · C# · TS
    Snippet-->>Reader: copy-to-clipboard

Every edit in the form regenerates every snippet. The exported curl / grpcurl / typed-client code carries the exact values the reader just typed — no hand-curated example to drift away from the live shape.

Authoring offline from a schema file

Docs writers don't need a running service to author an example. Point Bowire at a .proto / OpenAPI document / GraphQL SDL — the workbench loads the schema and lets the writer compose a request even before the implementation is live.

The schema-upload path serves two cases: 1) the API is still being built and the docs need to ship before the service does; 2) the API is third-party / external and you can't always run it locally. Either way, Bowire builds the same method tree, generates the same typed inputs, exports the same code snippets — only the “send and see the response” step requires a real target.

When the service does come up, switch the environment dropdown to point at it — the inputs the writer already authored carry over.

Offline-from-schema feature reference →

Make the docs runnable

Embed the workbench, export real code, author offline against a schema file — one tool covers all three.

Docs-team workflow Quickstart (embedded path) Feature reference

A different lane fits better? All solution lanes →