SBproxy emits OpenAPI 3.1 directly from the policy graph. Every route, auth method, rate limit, and cache rule is generated from the config that already runs in production. Drift is impossible because there is no second source.
# sb.yml: one origin, one route, one auth, one rate limit
origins:
"api.example.com":
expose_openapi: true
action:
type: proxy
url: https://upstream.internal:8443
authentication:
type: api_keys
header: X-API-Key
forward_rules:
- rules:
- path: { template: /users/{id} }
parameters:
- name: id
in: path
required: trueEvery team that ships an API ships at least three artifacts that claim to describe it. The spec, the gateway config, and the consumer integrations. They start aligned. They do not stay aligned.
One source of truth closes all three drifts.
A platform engineer renames a field. A security lead tightens an auth scheme. The gateway picks the change up on the next reload. The OpenAPI file in your docs repo learns about it weeks later, if at all.
Your spec says bearer token. The gateway runs JWT with JWKS rotation, or mTLS, or an API key plus IP allowlist. Auditors notice. Partners hit 401s the SDK stubs never anticipated.
One spec generates dozens of artifacts. Each generation freezes the surface at a moment that no longer matches the gateway. New routes are missing. Removed routes are still callable in stub code that did not get the memo.
The policy graph that runs in production is the same artifact that emits the spec. Routes, auth schemes, rate limits, and response shapes come from the YAML the gateway already compiled. There is no second pipeline to keep honest.
Deterministic output. Byte-stable across reloads so a Git diff of the emitted spec only changes when the config changes. Schemas, security schemes, error responses, and examples come from the YAML the gateway runs.
Reject non-conforming requests at the gateway, before they reach your service. Optional shadow mode logs violations without blocking, so a rollout never breaks existing partners. The validator runs on the same compiled chain as auth.
Point an MCP client, a Postman workspace, or a partner SDK generator at the same emitted spec. Each consumer reads the live shape of the API. When the gateway changes, every consumer sees the change on its next fetch.
Twelve lines of origin config produce the OpenAPI 3.1 fragment below. Reload the gateway and the document follows. Diff the output in CI to catch breaking changes before they ship.
origins:
"api.example.com":
expose_openapi: true
action:
type: proxy
url: https://upstream.internal:8443
authentication:
type: api_keys
header: X-API-Key
policies:
- type: rate_limit
requests_per_minute: 120
response_cache:
cacheable_status: [200, 404]
forward_rules:
- rules:
- path: { template: /users/{id} }
allowed_methods: [GET]openapi: 3.1.0
info:
title: api.example.com
version: 1.0.0
servers:
- url: https://api.example.com
paths:
/users/{id}:
get:
parameters:
- name: id
in: path
required: true
schema:
type: integer
responses:
'200': { description: OK }
'404': { description: Not Found }
security:
- apiKeyHeader: []
x-rate-limit:
requests_per_minute: 120
x-cache-policy:
cacheable_status: [200, 404]
components:
securitySchemes:
apiKeyHeader:
type: apiKey
in: header
name: X-API-KeyValidation runs on the same policy graph as auth and rate limiting. There is no separate validator service to staff, no second hop to manage, no extra place where the contract can fall behind reality.
For engineers in the buying committee. The capabilities behind the outcomes above.
The gateway is on GitHub under Apache 2.0 and you can install it right now, so nothing here is gated behind a sales call. Use this form for deployment questions, migration scoping, or anything you would rather not file as a public issue.