Furries PH Docs
Dashboard
Platform API docs

Foundations

What Is partners-api?

Plain-language foundation for the platform API and where it fits in the Furries PH system.

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.

Explanation

partners-api is the Cloudflare Worker API layer used by partner dashboard tools, rego attendee flows, Event Management, EMS LAN support, webhooks, and selected public surfaces. It uses Hono route modules under src/routes and mounts them from src/index.ts.

Question list

  1. Question 1 - Who is the caller? Identify whether the request comes from partner dashboard, rego, EMS LAN, a webhook, a public form, or an internal test tool.
  2. Question 2 - What records can change? Check whether the route touches attendees, staff, events, payments, reports, files, or integrations.
  3. Question 3 - What side effects can happen? Look for email, Discord, Telegram, Google Wallet, Sanity, deployment hooks, GitHub releases, or database writes.
  4. Question 4 - What breaks if it changes? Search dashboard, rego, LAN, and docs consumers before changing payloads or status codes.

Checkpoints

  1. Checkpoint 1 - Mounted route found: The endpoint exists in Generated Route Inventory.
  2. Checkpoint 2 - Auth model known: The route has an inspected auth model, not just an assumption from its folder.
  3. Checkpoint 3 - Consumer known: At least one consumer or intended caller is documented.
  4. Checkpoint 4 - Failure behavior known: The caller can safely handle expected errors.

All docs