ChatalyzeDocs

Documentation

Maintaining this wiki

Process so documentation stays equal to what is live on the site and API.

Golden rule

If it ships to production, the wiki ships with it.Docs live in apps/web/src/pages/docs/** and deploy vianpm run deploy:web to chatalyze.co/docs.

Two layers of truth

LayerLocationAudience
Public wiki (canonical UX)apps/web/src/pages/docs/**Operators, integrators, you
Nav registryapps/web/src/lib/docs-nav.tsSidebar + index cards
Agent mirrors (optional summaries)docs/wiki/**Coding agents, offline
Deep engineering notesdocs/*.md, docs/adr/*Implementers (not always public)

When you must update docs

  • New or renamed API route → API reference pages + root routes in Worker
  • New dashboard page → Product → Dashboard table
  • New alert code or default → Alerts catalog
  • Auth / secret change → Essentials → Auth / Environments
  • OnlyFansAPI vendor credit rule change → Essentials → Credits (re-check upstream)
  • Deploy with new health.version → Changelog

Agent checklist (every PR that touches product)

  1. Does docs-nav.ts need a new page?
  2. Update the public wiki Astro page(s)
  3. Update docs/wiki/README.md index if structure changed
  4. Update Worker routes map on GET / if API changed
  5. Point API docs field athttps://chatalyze.co/docs
  6. npm run build:web — confirm /docs/** pages build

Style guide (match OnlyFansAPI quality bar)

  • Lead with what the reader needs to do
  • Tables for endpoints, flags, and costs
  • Callouts for warnings, external dependencies, and live constraints
  • Copy-pasteable curl examples against production hosts
  • Link to vendor docs for external systems; do not invent credit numbers
  • Separate live vs shipped-in-repo / pending deploy when they diverge
Live probesWelcome + API overview + Changelog fetch production health/routes in the browser so readers can spot drift even if a static page is slightly stale.