Appearance
IE.5: Booking Emails and Notifications
Summary
Booking actions trigger email and in-app notifications for clients and counselors. Public or authenticated booking creation can immediately confirm a booking or create a pending request. Confirmation, cancellation, and reschedule events reuse templated email delivery and in-app notification delivery.
Role
- Primary: Guest, Client, Counselor
- Secondary: System, Resend
Entry Point
- Public booking:
/book/:slug - Embedded booking:
/embed/book/:slug - Client bookings:
/my-bookings - Counselor booking management:
/booking-settings - API examples: booking create, confirm, cancel, reschedule, approve reschedule, reject reschedule
Preconditions
- Booking widget and session type exist.
- Requested slot is available.
- Email service and notification templates are optional but required for actual email/in-app delivery.
Steps
- Guest or client books a session from a counselor booking page.
- Backend validates availability, creates the booking, and sets status from the widget confirmation mode.
- Backend starts post-booking work asynchronously.
- If instant-confirmed, backend creates a linked meeting and sends
booking_confirmedto the client plusbooking_request_newto the counselor. - If request-mode, backend sends
booking_receivedto the client andbooking_request_newto the counselor. - Backend creates in-app notifications for authenticated recipients using the same event context.
- Counselor can confirm a pending booking; backend creates a meeting and sends
booking_confirmed. - Counselor or client can cancel eligible bookings; backend cancels linked meetings where present and sends
booking_cancelledto the non-actor. - Client can request a reschedule; backend validates the new time and sends
booking_reschedule_requested. - Counselor approves or rejects the request; backend updates the booking/linked meeting and sends
booking_rescheduledorbooking_reschedule_rejected.
Diagram
Edge Cases
- Slot conflict: Booking creation returns
slot_takenwhen the database exclusion constraint detects overlap. - Email failure: Booking actions still succeed; email failures are logged.
- Actor suppression: Later booking notifications skip notifying the user who performed the action.
- Guest booking: Guest email receives email when available; in-app notification requires a
ClientUserID. - Linked meeting failure: Meeting creation failures are logged and do not roll back the booking.
- Linked meeting compensation: If meeting creation succeeds but booking link fails, backend attempts to cancel the orphaned meeting.
- Reschedule conflict: Reschedule request and approval both re-check conflicts.
- Expired reschedule proposal: Approve rejects proposals whose requested start has passed and clears the request.
Current Implementation Notes
- Backend:
backend/internal/services/booking_service.go - Frontend:
frontend/src/features/booking/components/public-booking-page.tsx,frontend/src/features/booking/components/my-bookings.tsx,frontend/src/features/booking/components/bookings-management.tsx - Templates:
backend/scripts/seeds/006_seed_booking_email_templates.sql
Screenshot Status
- Not captured.