Routes

Optional app role and permission endpoints are listed in the authorization reference. Existing administrative app actions use exact library permission checks when app permissions are enabled.

Every HTTP route the library mounts, the request it expects, and the response it returns. Auth on each route is Public (no session needed) or Session (the session cookie is required). With app permissions disabled, admin routes require role: "admin". With app permissions enabled, app administrative actions use their exact library permission keys; catalog provisioning and organization oversight require the protected admin identity. Required MFA assurance still applies. See Admin and App authorization.

Conventions used on every page:

• Request and response bodies are application/json with camelCase fields. No streaming, no file uploads, no multipart forms.
• Success responses carry a message plus route-specific fields, except 204 No Content (no body) and a few list/count routes documented per page. Failures use the {"error": code, "message": ...} envelope; see Error handling for the taxonomy.
• Tokens travel in cookies (goauth_session, goauth_refresh by default), never in bodies. State-changing requests need Origin and X-CSRF-Token; see Security.
• Some route groups are conditional: POST /auth/register needs EmailPassword; invite routes need InviteSignup; OAuth routes need authentication OAuth plus a registered provider; org routes (both self-service and admin) need organizations enabled. Unmounted groups are not 404 fallthroughs: the paths simply do not exist.

Pages

Audit reads live under Admin (GET /admin/audit-logs and per-user variants). There are no user-scoped audit routes.

Next

• Error handling: the complete error taxonomy
• Security: session security, CSRF, and rate limiting