Locations
Create and manage locations, timezones, weekly hours, and associations so services and resources can book in the right place and time.
Role in the hierarchy
Locations sit under a company and anchor timezone, operating hours, and which services and resources apply. For the full model, see Architecture: company vs location.
Core API surface
Authenticated company API (Bearer + company context). Exact query parameters and bodies are in the API reference.
| Area | Base paths | Notes |
|---|---|---|
| Collection | GET /v3/locations, POST /v3/location | List and create (plus POST /v3/location/bulk where supported) |
| Single record | GET/PUT/DELETE /v3/location/:id | Read, update, soft-delete patterns per your account rules |
| Weekly hours | GET/POST /v3/location/:id/weeklyAvailability | Schedule-mode baseline for the location |
| Associations | POST .../setAssociations, PUT .../addAssociations, PUT .../removeAssociations | Link related entities as your integration requires |
Set each location’s IANA timezone so GET /v3/availability and appointments interpret local dates correctly.
Settings and limits
Company- and entity-level booking rules often reference location context. See Settings overview and Booking limits.
Holidays (v3 API)
Company-scoped holiday sets are available on the holidays routes (see Platform API utilities for a short overview). Legacy v1-style per-location holiday CRUD is described in the v1 alias endpoints guide if you still use that shim.
Public and unauthenticated flows
Customer-facing listing of locations for a public client uses GET /v3/public/locations (with API key + public client id). See Authentication.
Related documentation
- Get started — First requests and environment
- Settings overview — Company and location settings
- Availability — Slots are computed per location and timezone
- Entity operating hours — How weekly hours layer with allocations and blocks
Updated 4 days ago