API Routes & Admin Interface
The meetingscribe application organizes its HTTP endpoints into modular route files to maintain a flat import structure and avoid circular dependencies. Each module declares an APIRouter instance and its associated handler functions, which are then registered with the main FastAPI application in server.py via app.include_router(router) during construction 1. These route modules rely on shared state from meeting_scribe.runtime.state and shared helpers from meeting_scribe.server_support, but they are strictly prohibited from importing from meeting_scribe.server to prevent cycles.
Route Module Structure
Section titled “Route Module Structure”The routing layer is designed to extract logic from the main server file into distinct modules. This approach allows for cleaner separation of concerns while ensuring that the parity test can detect any accidental circular imports if the convention of not importing from meeting_scribe.server is violated.
Authentication and Guards
Section titled “Authentication and Guards”The provided source documentation for src/meeting_scribe/routes/__init__.py describes the structural organization and import constraints of the route modules but does not detail specific authentication guards, OIDC implementations, or bearer token handling within the route modules themselves. The overview notes that server.py handles the inclusion of routers, but specific authentication logic per route is not described in the available text.
"""HTTP route modules - APIRouter-based extraction of ``server.py``.
Each module declares a ``router`` (``APIRouter`` instance) plus the
handler functions, then ``server.py`` calls
``app.include_router(router)`` once per module during app
construction. Route modules import shared state from
``meeting_scribe.runtime.state`` and shared helpers from
``meeting_scribe.server_support``; they MUST NOT import from
``meeting_scribe.server`` (the parity test would catch the cycle, but
the convention keeps imports flat).
"""