Repost publishes your event catalog as a public documentation site: one page per event type, with its description, payload schema, and samples. The content is generated from your deployed schema and rebuilt automatically on every deploy, so it always matches what production sends.
The source is the schema itself. A /// doc comment on an event member becomes the event's description, the model becomes its JSON Schema, and versions follow your migrations. There is no separate documentation to write or forget to update.
Two views of the same catalog#
The public site is for anyone evaluating or integrating against your webhooks. It has a public URL, needs no login, and can be linked from your own documentation.
The portal shows the same catalog to your existing customers, with two additions: downloadable type definitions, and a button that sends a sample event to their own endpoint.
Configuration#
The settings live in the dashboard under Settings → Docs:
| Setting | What it does |
|---|---|
| Slug | The site's public URL segment, unique across Repost. |
| Published | The visibility switch, on by default. Turning it off takes the site down until you turn it back on. |
| Page title | The browser title and site heading. |
| Logo & favicon | The site's visual identity, on top of the shared theme. |
Colors come from the same theme tokens as the portal, so both surfaces match. Theme and docs-settings changes trigger a rebuild, the same as schema deploys. There is nothing to redeploy manually.
Linking from your own docs#
Point the webhooks section of your documentation at the site, or deep-link a specific event page such as /events/order.created from the feature that emits it. Pages exist for exactly what is deployed: archived event types drop off and new ones appear with the deploy that ships them.