Unavailability and recurring blocks

When to use these APIs

• Ad-hoc blocks — Block a resource (or related entity) for vacation, training, or maintenance for specific date ranges.
• Recurring closures — Repeat the same closure pattern (for example, “every Friday after 3pm”) without re-entering each occurrence.
• Calendar views — Fetch unavailability as per-interval rows for custom UIs (source, affected entity, reason metadata).

GET /v3/availability and booking flows already respect these layers; configure blocks here when customers need to see fewer slots or when you must prevent booking during specific times.

Where to read next

• One-off stored blocks and calendar views (/v3/unavailability) — Unavailability blocks.
• Recurring rule-based closures (/v3/unavailability/recurringBlock) — Recurring blocks.

For types of calendar rows (appointments, holds, padding, OOF, external), see Unavailability in the glossary.

How this fits the stack

• Entity operating hours — Baseline hours and layers (allocations, blocks, external calendars) are described in Entity operating hours.
• Single and weekly allocations — Alternative ways to express availability, especially in allocation mode; see Single allocations and Weekly allocations.
• External calendars — Personal busy times often appear as unavailability; see External calendar sync.

Tips

• Prefer narrow date ranges when listing blocks; large windows are slower to query and render.
• After changing blocks or recurring rules, run a focused GET /v3/availability test for the affected resource and dates to confirm slots match expectations (responses may be cached briefly).
• For product terminology, use the Glossary.

Related documentation

• Resources overview — How resources use schedules and blocks
• Availability guide — How GET /v3/availability uses these layers
• Error codes — Common validation and conflict responses