OpenAPI Specification

Zuse Bifrost publishes a full OpenAPI 3.1 description of every /v1/* endpoint and every outbound webhook event. The document is generated from the application itself: the request validation rules, the API resources, the return types and the webhook catalogue are all inspected, and its prose is maintained beside that code, so there is no hand-written YAML to rot.

The same document builds this site's API Reference, one page per operation with its playground, and the webhooks' Event Reference, one page per event. What you read there is exactly what a client generated from the spec sees.

Where it livesCopy Anchor Link

Both files are served from the API host, the address your tokens call, and regenerated on every release so neither drifts from the code.

curl https://api.example.test/openapi.json -o zusegenius-openapi.json

Replace api.example.test with your workspace's API host.

What the document carriesCopy Anchor Link

• paths: every operation with a summary, a description covering tenancy, behaviour and refusals, every parameter and body field described with its type and constraints, the error envelope on each failure status, and request and response examples.
• webhooks: every outbound event, keyed by its name, described as the POST your endpoint receives: the signed envelope, the data object field by field, a named payload example, and the ZG-* headers.
• components.securitySchemes.bearerToken: the personal access token, so a generated client or a playground knows to send Authorization: Bearer.
• servers: the one host the document describes.

Vendor extensionsCopy Anchor Link

Every operation carries three x- extensions, and every webhook entry carries the first of them:

{
  "paths": {
    "/v1/teams/{team}/members": {
      "post": {
        "summary": "Invite a team member",
        "x-required-scopes": ["team-member:invite"],
        "x-webhook-events": ["team.member_invited"],
        "requestBody": { "...": "..." }
      }
    }
  }
}

Tooling reads them to generate permission-aware clients and agent toolkits without inspecting the server, and the reference pages on this site render them as the badge row above each operation.

Typical consumersCopy Anchor Link

• Postman and Insomnia: import the JSON URL and let the app build a collection by tag; every write needs an Idempotency-Key header, which the reference explains.
• openapi-generator, Stainless, Speakeasy, Fern: produce a typed client in any language. x-required-scopes ends up as comments in the generated source.
• LangChain and custom agents: expose every endpoint as a tool, or hand the spec to an agent beside a personal access token and let it compose requests. The MCP server is the purpose-built door for that.
• Webhook consumers: generate the payload types for your handlers from the webhooks object, so a renamed field is a compile error rather than a silent undefined.

RelatedCopy Anchor Link

• API Reference: the document rendered as pages, with a playground on each.
• Event Reference: every webhook event's envelope and payload, from the same document.
• Ability catalogue: the strings that appear in x-required-scopes.
• Errors: the envelope every operation can return on failure.