We use Scheduler v3 (EU region) with public configurations. Clients pick a slot in ; we intercept timeslotConfirmed and create the booking server-side with our API key (POST /v3/scheduling/bookings?configuration_id=…). Availability comes from GET /v3/scheduling/availability.
Each configuration has scheduler.min_booking_notice (e.g. 720 minutes) so clients can’t book at short notice. But our organizers also propose sessions to their clients, e.g. “today at 18:00” at 14:00. Those bookings are blocked by the same notice, even though the organizer started them.
1. Is there a supported per-request override (parameter, header, or session option) that skips min_booking_notice for GET /v3/scheduling/availability and/or POST /v3/scheduling/bookings when calling with the API key?
2. Does POST /v3/scheduling/bookings check min_booking_notice itself, or is it only applied to availability results?
3. Can a session from POST /v3/scheduling/sessions carry a different notice than its configuration?
4. If none of these exist, what do you recommend? A second configuration per event type with notice 0, or notice 0 everywhere with our own enforcement? With the second, is ui-settings’ min_booking_notice only a client-side clamp in the web component?
5. Is a per-booking override on the roadmap?
Thanks!
Hello Renato,
Thanks for contacting Nylas Support. We’d be happy to help.
1 - There isn’t a documented per-request override for min_booking_notice. Neither GET /v3/scheduling/availability nor POST /v3/scheduling/bookings accepts a parameter, header, or body field to skip it, including when calling with your API key. The notice is set only on the Configuration through scheduler.min_booking_notice.
2 - The booking endpoint validates against availability: the start_time and end_time must match a valid time slot returned by Get availability, which already applies the minimum notice. That’s why bookings inside the notice window are rejected even when they’re created server-side.
3 - No. POST /v3/scheduling/sessions only accepts configuration_id, slug, and time_to_live, so a session always uses its Configuration’s settings.
4 - We’d recommend a second Configuration per event type for organizer-proposed sessions, with min_booking_notice set to 0 and requires_session_auth set to true, so only your backend can create sessions for it and clients can’t use it to book at short notice. Your public Configuration keeps the 720-minute notice for client self-booking. Alternatively, since the organizer is choosing the time directly, you can create the event with the Events API and skip the booking flow for those sessions. We’d recommend against setting the notice to 0 everywhere and enforcing it only on your side, since that removes the server-side protection for public bookings.
References: Create a booking, Create a session, and the scheduler.min_booking_notice field in Create a Configuration.
Many thanks,
Samuel R.
Support Engineer, Nylas