Permissions and Roles

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.

Role classification

1. Action 1 - Classify the route: Public, dashboard-authenticated, rego-authenticated, partner-admin, event-scoped, platform-admin, webhook, internal, or test-only.
2. Action 2 - Find enforcement source: Link the middleware, helper, or inline check that proves the role.
3. Action 3 - Check record scope: Verify partner ID, event ID, attendee ID, staff profile ID, or payment account scope.
4. Action 4 - Document escalation: If only FPH staff or platform admins can call it, say why.

Permission matrix

Caller	Typical route group	Required proof
Public user	contact, public waitlist, public integration callback	validation, abuse controls, signed state where applicable
Attendee	rego, fursonas, social, rego notices	rego session and attendee/event scope
Partner operator	events, reports, admin, finance, HR	dashboard session plus partner/event permission
Platform admin	network bans, org control, test tooling	dashboard session plus elevated role
System	hooks, cron, test control	signed webhook, shared secret, or guarded internal header