Generation

Your docs rot the moment they leave the code. Not here.

Gravity reads your source and your API gateway and writes the reference for you, then binds every fact to the code it came from. When the code moves, the docs move with it, so your reference never quietly falls out of date.

Bound to source
gateway.go
r.POST("/v1/keys/rotate",
    rotateKey)
API reference
POST/v1/keys/rotate
The pipeline

Your code is the input

Source files and your API gateway — the truth Gravity reads from.

Drift, caught in your pipeline

CI tells you the docs are wrong before your customers do

A check runs on every pull request. When the code changes outpace the reference, Gravity opens the fix as a proposal, so the docs are corrected before they reach a reader, not weeks after.

  • Runs as one step in the pipeline you already have
  • Notices new, changed and removed endpoints
  • Proposes the exact edit, ready to review and merge
ci · docs-drift check

Per-block ownership

You own the words. We keep the facts.

A Gravity page is a mix of your words and bound facts. Point at a block to see who owns it. The facts can never silently drift; the prose is always yours.

This block is

Hybrid block

Your words around a fact that stays bound to the code.

You wrote this
Hybrid block
Bound to source

The generated reference

A reference your team trusts on sight

The API reference Gravity produces from your gateway and source: every endpoint, parameter and type, organised by service, ready to publish on your own domain.

A map of your whole codebase
Services, packages and module boundaries laid out automatically, so a new engineer can navigate the system on day one.
Typed, end to end
Endpoints, methods, parameters and types derived from your gateway and source, with OpenAPI generated where you do not already have it.
Product screenshot: the generated API reference screen — left-hand service/endpoint tree, a selected endpoint showing method, path, parameters, request and response types, and the bound-to-source badge.

Stale wiki vs always-true reference

The difference your readers feel

The same endpoint, kept two ways. One drifts the moment an engineer ships a change; the other is bound to the code and corrects itself.

Hand-kept wiki edited 7 months ago

POST /v1/keys/rotate

  • Body: keyId (string)
  • Old key valid for 1 hour
  • Header X-Idempotency-Key not mentioned
  • Returns the new key

Two facts are already wrong. Nobody noticed, because the code shipped and the page didn’t.

Gravity referencein step with main

POST /v1/keys/rotate

  • Body: keyId (string)
  • Old key valid for 24 hours
  • Header X-Idempotency-Key (recommended)
  • Returns key (string), expiresAt (timestamp)

Every field is bound to the gateway. The 24-hour window and the new header arrived with the code that changed them.

0
endpoints documented automatically
0
drift fixes proposed in CI last quarter
0
reference pages edited by hand to keep them current
0%
of generated facts bound to a source

See it on your own code.

Point Gravity at your repo and publish your first always-true reference today.