The availability window is thirty days and every slot is checked twice

The availability API accepts a date and a duration. The date must be in YYYY-MM-DD format. The duration must be 15, 30, 45, 60, 90, or 120 minutes — anything else is rejected. Bookings more than thirty days out are blocked before the Google Calendar query even runs. The API fetches real calendar events from Google, finds gaps in the schedule, and returns an array of available slots. Each slot has a start and end time. The ConsultationPicker component on the front end renders these as a grid of buttons — one per slot, grouped by day. When a client picks a slot and hits confirm, the booking API receives the start time and duration. Before creating the calendar event, it calls getAvailableSlots again with the same date and duration. It checks whether the requested start time still exists in the returned array. If someone else booked that slot between the page load and the confirm click, the slot is gone. The API returns a 409 conflict with a message telling the client to choose another time. The booking only proceeds if the slot survives both checks — the initial load and the confirmation request. The actual calendar event is created via createBooking, which returns the start time, end time, and a Google Meet link if conference data exists. The booking confirmation email includes the date formatted as a full weekday and month, the time in 24-hour UK format, the service label, and the Meet link. If the booking came from the checkout confirmation page — where the client just paid for a package — the skipEmail flag is set to true and no email fires because the Stripe webhook already handled that. Two checks, one calendar, zero double bookings.