Current reality
TIBS now exposes one dedicated shared backend service throughtibs-api.
The wider live integration surface is still split across:
- the dedicated NestJS backend in
api - Next.js route handlers in
tibs - Next.js route handlers in
tibs-survey - route handlers and callback routes in
tibs-learning-center - direct browser or server calls to Supabase RPCs and tables where app-local behavior still exists
Interface classes
Repo-by-repo split
api
The shared backend now exposes centralized routes for:
- health and session identity
- scoped external API keys
- reports, incidents, vehicles, feedback, corridors, routes, saccos, and search
- learning progress and course listing
- surveyor session and stats endpoints
- admin review and role provisioning
tibs
The main rider app exposes public-facing route handlers for:
- incident feeds
- vehicle lookup
- map search and corridor map data
- coverage overlays
- location context
- report submission
- QR scan
- quick rating
- incident voting
tibs-survey
The operations app exposes restricted routes for:
- session start, touch, and end
- assignment claim and release
- vehicle collection submissions
- catalogs for corridors, routes, saccos, and vehicle lookup
- surveyor profile and payout settings
- expenses and withdrawal requests
- admin review and configuration
- Brevo webhook ingestion
tibs-learning-center
The learning-center repo currently does not expose a normal app/api
directory.
Its live interface layer is instead:
- auth callback bootstrap and finalize routes
- sign-in, sign-up, recovery, and sign-out routes
- browser-side Supabase reads and writes for learning progress
- RPC
mark_learning_module_progress
Documentation rule
When writing API docs for TIBS, distinguish clearly between:- the dedicated
tibs-apiservice and its generated OpenAPI contract - live app routes that already exist
- internal Supabase RPCs used behind those routes
- app-local proxies or callbacks that are not the same thing as the shared API