API Overview
:::info Status
Implemented — generated from the live FastAPI OpenAPI spec (127 endpoints as
of this writing). Regenerate with npm run gen-api-docs after backend route
changes; see the site README.
:::
Every page under API Reference is generated directly from
fastapi-backend's OpenAPI schema (app.openapi()) — not hand-written, so
it cannot drift from the code's response_models and path operations. If an
endpoint here looks wrong, the fix is in the backend's route/schema, then a
regeneration — never a hand-edit of a generated .mdx file under docs/api/.
Authentication
Most endpoints require a JWT bearer token issued by /api/v1/auth/* — see
Authentication. Superadmin-only endpoints
are additionally gated by security.require_role(["superadmin"]), visible
per-endpoint in the generated docs below.
Device-facing endpoints (/device-registry/*, /mosque-devices/*) use a
different trust model — see Device Authorization
before assuming a bearer token applies.
Grouped by tag
| Tag (router prefix) | Covers |
|---|---|
auth | Login, signup, superadmin 2FA |
users | User profile, push token registration |
mosques | Mosque CRUD, admins, activity |
memberships | Mosque membership approval |
invites / join | Invite-code and join-code flows |
devices | Legacy simple device CRUD |
device-registry | Unified device inventory: announce, claim, approve, transitions, ownership transfer, replace |
mosque-devices | Transmitter/stream-player claim, config, commands, health |
my-devices | A member's own bound devices — rebind/unbind |
app-installs | Mobile app install enrollment, push token, preferences |
triggers | Manual broadcast/azaan triggers |
azan-auto | Offline-azan scheduler settings/status/history |
audio-files | Azan recording upload/management |
broadcast-audit | Delivery analytics per broadcast |
prayer-times | Prayer time timetable and location |
events / announcements | Mosque events and announcements |
device-invoices | Device sales invoicing |
stream-auth | Scoped stream listener tokens |
super-admin | Platform-wide operations (e.g. republish-retained) |
Module-level behavior for the more involved domains is documented under Modules, not repeated here — this reference is the wire contract (request/response shape), not the "why."