Rules reference
There are three types of rules, each with a different enforcement level. Understanding the difference matters when your agent receives a NO_SLOTS_AVAILABLE or REJECT response.
Working hours
What it does: Defines when the calendar is open for booking. When working hours are configured, any slot that falls even partially outside those hours is never offered and is rejected at confirmation.
Configured in: Dashboard → Rules → Working hours
Example: working hours Mon–Fri 09:00–17:00 UTC means no meeting can start before 09:00 or end after 17:00 on those days. Weekends return no slots because they are outside the configured schedule.
Agent response when violated:
{ "error": { "code": "NO_SLOTS_AVAILABLE" }, "reason_code": "WORKING_HOURS" }
on POST /v1/availability/search, or:
{ "error": { "code": "ARBITRATION_REJECTED", "reason": "WORKING_HOURS" } }
on POST /v1/bookings/confirm.
Working hours not yet configured: If no working hours have been set, Openavail does not enforce a day-of-week or time-of-day boundary. Availability and booking calls still work, but responses include a WORKING_HOURS_NOT_CONFIGURED warning. Agents should treat evenings, weekends, and unusual local times with extra care and confirm before booking.
Slot interval
What it does: Controls the granularity of the availability grid — both the step between candidate slots and the snap boundary for the search window start.
Configured in: Dashboard → Rules → Working hours → Meeting start times
| Value | Slot boundaries offered |
|---|---|
| 15 (default) | :00, :15, :30, :45 |
| 20 | :00, :20, :40 |
| 30 | :00, :30 |
| 60 | :00 (top of hour only) |
Valid values are any divisor of 60 (1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, 60).
How window snapping works: If you request a window starting at 11:07 with a 15-minute interval, the first slot offered is 11:15, not 11:07. The window start snaps forward to the next boundary. A window that already starts on a boundary (e.g. 11:00) is unchanged.
Agent guidance: Use a slot interval that matches your product's UX. A sales booking tool might use 30-minute slots; a high-frequency scheduler might want 15. If the calendar owner changes the interval after you have quoted alternatives to a user, refetch availability before confirming.
Blocked times
What it does: Hard constraints that stop bookings outright. There are two kinds:
Named recurring blocks
Time windows that repeat on selected days — lunch breaks, school pickups, no-meeting Fridays. Any slot that overlaps a named block is excluded from availability results and rejected at confirmation.
Agent response when violated:
{ "error": { "code": "ARBITRATION_REJECTED", "reason": "NO_CAPACITY" } }
Max meeting hours per day
A daily quota. Once the calendar owner has accumulated this many hours of committed bookings on a given day, no more slots are offered for that day — POST /v1/availability/search returns NO_SLOTS_AVAILABLE immediately without offering any slots to confirm.
This is a hard limit, not a preference. A slot will never be offered if accepting it would push the owner over their daily cap.
Agent response when limit is reached:
{ "error": { "code": "NO_SLOTS_AVAILABLE" }, "reason_code": "DAILY_HOURS_LIMIT" }
Preferences
What it does: Soft signals that influence which slots are ranked highest in the availability response. Nothing is ever blocked — slots that violate a preference still appear, just lower in the list.
| Preference | Effect |
|---|---|
| Min buffer between meetings | Slots adjacent to an existing meeting are penalised but not removed |
| Max back-to-back meetings | Slots that would extend a back-to-back chain past the limit are penalised |
Agent guidance: Preferences are signals for the human or AI in the loop. If the top-ranked slot is not ideal, earlier slots in the list are not blocked — they are simply less preferred by the calendar owner's configuration.
How rules affect agent responses
| Rule | Checked at availability | Checked at confirm | Response code |
|---|---|---|---|
| Working hours, when configured | Yes | Yes | NO_SLOTS_AVAILABLE / WORKING_HOURS |
| Named block | Yes | Yes | NO_SLOTS_AVAILABLE / NO_CAPACITY |
| Max meeting hours/day | Yes | Yes | NO_SLOTS_AVAILABLE / MAX_DAILY_HOURS |
| Preferences (buffer, back-to-back) | Reorders only | No enforcement | — |
Rules are enforced from the current rule set at the time of the confirm call, not the rule set in effect when the hold was created. If a calendar owner tightens their rules between hold creation and confirmation, the tighter rules apply.