Rout Courts: how the frontends connect and share data

One backend project backs every app below. Lines show what actually calls what. No app talks to another directly, and none can claim someone else's identity: that's resolved server-side.

Client applications: separate bundles, separate logins
Admin Portal
Staff only. Calendar, approvals, courts, coaches, sessions, payments, reports.
Coach Portal
Coach login. Request and manage own bookings only.
Parent Portal + Mobile
Parent login. Timetable, booking, waitlist, payment, children. Same app, responsive.
Calls go over HTTPS. Identity is resolved server-side, never trusted from the request.
Backend functions: the only door in
admin-api
Calendar, approvals, courts, coaches, reports
coach-api
Booking requests, recurring series
parent-api
Booking, waitlist, children, checkout
payments-webhook
The payment platform confirms payment here, not the app
Writes run through service-role-only functions. Row Level Security stays closed. The edge function is the enforcement boundary.
Core platform: one managed backend
Database
Venues, courts, bookings, sessions, payments, waitlists
Authentication
One user pool, three roles: staff, coach, parent
File storage
Coach documents, agreements
Scheduled jobs
Waitlist promotion, SMS reminders
External services
Payment platform
Pay-online checkout, confirms via webhook
Email platform
Invites, confirmations, receipts
SMS platform
SMS reminders