Furries PH Docs
Dashboard
Platform API docs

Foundations

Platform Boundaries

How to decide what belongs in partners-api versus dashboard, rego, EMS LAN, Supabase, Sanity, or docs.

First created Last updated

End-to-end developer runbook

  1. Step 1 - Confirm the API area: Identify the product area, route module, endpoint path, and consumer before writing or calling code.
  2. Step 2 - Read the endpoint contract: Check method, auth, parameters, response, errors, side effects, and related docs.
  3. Step 3 - Prepare authentication and input: Use the right session, bearer token, webhook secret, or internal header. Validate body and query data before sending it.
  4. Step 4 - Make the request: Call the endpoint from the correct origin and environment. Keep credentials and secrets out of logs.
  5. Step 5 - Verify response, side effects, and records: Confirm status code, response shape, database records, external side effects, and audit evidence.
  6. Step 6 - Add tests, docs, and handoff notes: Update route inventory, consumer notes, and certification checks before depending on the change.

Boundary rules

  1. Action 1 - Put server secrets only in partners-api: Cloudflare Worker bindings can hold Supabase service keys, OAuth secrets, webhook secrets, and integration tokens. Browser code must not.
  2. Action 2 - Put user interface state in the consuming app: Dashboard, rego, and EMS LAN should own page layout and client-only interaction state.
  3. Action 3 - Put authoritative record changes behind API contracts: Anything that mutates attendee, event, finance, trust-safety, staff, or integration records needs route-level auth and validation.
  4. Action 4 - Put long-lived documentation in docs.furries.ph: Developer-facing behavior must be documented here and regenerated when routes change.

All docs