Skip to main content
Create, update, repeat, and enrich fixed slots in the admin API. This guide is grounded in the current backend JSON:API contracts and the admin frontend workflows used by the timeslot detail editor. For general conventions, see JSON-API Conventions. For booking lifecycle effects after a timeslot change, see Booking Lifecycle.

What a Timeslot Represents

A timeslot is a fixed start and end period attached to a resource or service. It can:
  • exist as a one-off slot
  • belong to one or more timeslot series
  • expose cached resource_info for cards and customer-facing summaries
  • use dynamic capacity based on resource allocations
  • have regular bookings linked to it
Core schema references:
  • reference/timeslots.v1.yaml
  • reference/timeslot-series.v1.yaml
  • reference/timeslot-resource-allocations.v1.yaml
Main endpoints:
  • GET /api/v1/timeslots
  • POST /api/v1/timeslots
  • GET /api/v1/timeslots/{timeslot_id}
  • PATCH /api/v1/timeslots/{timeslot_id}
  • DELETE /api/v1/timeslots/{timeslot_id}
  • POST /api/v1/timeslots/preview
  • POST /api/v1/timeslots/{timeslot_id}/extend

List and Filter Timeslots

Use the collection endpoint for admin calendar and editor views:
Confirmed query parameters: Resource-scoped reads are also available:

Create a Single Timeslot

Common attributes used by the admin UI:

Preview and Create Recurring Slots

The admin frontend does not blindly create recurring slots. It first previews generated occurrences, then saves one seed timeslot, then extends from that seed. Preview request:
Extend request:
Use the same recurring payload after the first timeslot has been created. The response returns the generated occurrences. Use series when you need a named grouping for recurring slots. CRUD is available on:
  • GET /api/v1/timeslot-series
  • POST /api/v1/timeslot-series
  • GET /api/v1/timeslot-series/{timeslot_series_id}
  • PATCH /api/v1/timeslot-series/{timeslot_series_id}
  • DELETE /api/v1/timeslot-series/{timeslot_series_id}

Manage Resource Allocations

Dynamic-capacity timeslots can attach secondary resources through timeslot resource allocations. Endpoints:
  • GET /api/v1/timeslot-resource-allocations
  • POST /api/v1/timeslot-resource-allocations
  • GET /api/v1/timeslot-resource-allocations/{timeslot_resource_allocation_id}
  • PATCH /api/v1/timeslot-resource-allocations/{timeslot_resource_allocation_id}
  • DELETE /api/v1/timeslot-resource-allocations/{timeslot_resource_allocation_id}
Useful fields: List filters include filter[is_required] in addition to status and visibility filters.

Reschedule or Update a Timeslot With Bookings

Updating a slot can affect linked regular bookings. When the period changes, the admin frontend sends extra query parameters on PATCH /api/v1/timeslots/{timeslot_id}. This is the flow used by the reschedule modal in the admin UI.

Retrieve Bookings for a Timeslot

Use the relationship endpoint to populate the Bookings tab:
This returns regular bookings currently linked to the slot.

Calendar Events and timeslot_id

Calendar event payloads can be correlated back to timeslot CRUD flows through timeslot_id. Use this when you need to:
  • open the matching timeslot editor from a calendar event
  • fetch the canonical timeslot resource after a calendar query
  • reconcile resource_info shown in calendar cards with allocation-backed timeslot data
For the aggregate calendar surface, see Booking Calendars.