calcom/cal.diy · error · BadRequestException
The event type can't be booked at the "start" time provided.
Error message
The event type can't be booked at the "start" time provided. This could be because it's too soon (violating the minimum booking notice) or too far in the future (outside the event's scheduling window). Try fetching available slots first using the GET /v2/slots endpoint and then make a booking with "start" time equal to one of the available slots.
What it means
Thrown by handleBookingError when the booking engine raised 'booking_time_out_of_bounds_error'. BadRequestException (HTTP 400). It means the requested start violates the event type's minimum booking notice or its scheduling window (future limit). The message points the caller to GET /v2/slots to obtain valid start times.
Source
Thrown at apps/api/v2/src/platform/bookings/2024-08-13/services/errors.service.ts:44
if (body.teamSlug && body.eventTypeSlug && body.organizationSlug) {
throw new NotFoundException(
`Event type with slug ${body.eventTypeSlug} belonging to team ${body.teamSlug} within organization ${body.organizationSlug} not found.`
);
}
throw new NotFoundException(`Event type with id ${body.eventTypeId} not found.`);
}
handleBookingError(error: unknown, bookingTeamEventType: boolean): never {
const hostsUnavaile = "One of the hosts either already has booking at this time or is not available";
if (error instanceof Error) {
if (error.message === "no_available_users_found_error") {
if (bookingTeamEventType) {
throw new BadRequestException(hostsUnavaile);
}
throw new BadRequestException("User either already has booking at this time or is not available");
} else if (error.message === "booking_time_out_of_bounds_error") {
throw new BadRequestException(
`The event type can't be booked at the "start" time provided. This could be because it's too soon (violating the minimum booking notice) or too far in the future (outside the event's scheduling window). Try fetching available slots first using the GET /v2/slots endpoint and then make a booking with "start" time equal to one of the available slots.`
);
} else if (error.message === "Attempting to book a meeting in the past.") {
throw new BadRequestException("Attempting to book a meeting in the past.");
} else if (error.message === "hosts_unavailable_for_booking") {
throw new BadRequestException(hostsUnavaile);
} else if (error.message === "booker_limit_exceeded_error") {
throw new BadRequestException(
"Attendee with this email can't book because the maximum number of active bookings has been reached."
);
} else if (error.message === "booker_limit_exceeded_error_reschedule") {
const errorData =
"data" in error ? (error.data as { rescheduleUid: string }) : { rescheduleUid: undefined };
let message =
"Attendee with this email can't book because the maximum number of active bookings has been reached.";
if (errorData?.rescheduleUid) {
message += ` You can reschedule your existing booking (${errorData.rescheduleUid}) to a new timeslot instead.`;
}View on GitHub (pinned to 176037d0af)
Solutions
- Always fetch GET /v2/slots first and book a start time it returns.
- Check the event type's minimumBookingNotice and bookingWindow and ensure start is within bounds client-side.
- If the slot list is empty for the desired window, widen the window or reduce the notice.
- Re-fetch the event type after config changes to refresh cached bounds.
Example fix
// before
start = dayjs().add(10, 'minute').toISOString(); // below 24h notice
// after
const slots = await api.get(`/v2/slots?eventTypeId=${eventTypeId}&startTime=${dayjs().toISOString()}&endTime=${dayjs().add(14,'day').toISOString()}`);
start = slots.data.slots[0]?.start; Defensive patterns
Strategy: validation
Validate before calling
const et = await api.get(`/v2/event-types/${eventTypeId}`);
const minNoticeMs = (et.data.minimumBookingNotice ?? 0) * 1000;
const windowMs = (et.data.bookingWindow ?? Infinity) * 24*60*60*1000;
const startMs = new Date(body.start).getTime();
if (startMs < Date.now() + minNoticeMs || startMs > Date.now() + windowMs) throw new Error('start out of bounds'); Type guard
null
Try / catch
try { await api.post('/v2/bookings', body); }
catch (e) {
if (e.response?.status === 400 && /can't be booked at the .start. time/.test(e.response.data.message)) {
/* re-fetch slots and use a returned start */
} else throw e;
} Prevention
- Always fetch GET /v2/slots and book a returned start.
- Re-fetch the event type after minimumBookingNotice or bookingWindow changes.
- Validate start is within notice+window client-side before POSTing.
When it happens
Trigger: Booking with a start time closer than the event type's minimumBookingNotice (e.g. booking 5 minutes out when notice is 24h), or further out than the event type's booking window (e.g. 6 months ahead when the window is 30 days). The engine throws booking_time_out_of_bounds_error and the service maps it to this guidance.
Common situations: Reduced minimumBookingNotice on the event type without updating the client; timezone mismatch making 'now' appear hours away; far-future bookings for planning that exceed the window; changed event-type scheduling window after the client cached an old slot.
Related errors
- One of the hosts either already has booking at this time or
- User either already has booking at this time or is not avail
- Event type with slug ${body.eventTypeSlug} belonging to user
- Event type with slug ${body.eventTypeSlug} belonging to user
- Event type with slug ${body.eventTypeSlug} belonging to team
AI-assisted analysis of calcom/cal.diy@176037d0af (2026-08-12).
Data as JSON: /api/errors/bb791675adb2f532.
Report an issue: GitHub.