Reservations Catalog
The Reservations catalog provides three distinct reservation systems, each with specialized features.
| Type | Use case | Duration unit | Key fields | SDK resource |
|---|---|---|---|---|
| Table | Restaurants, dining | Minutes | time, duration, personsNumber, floorPlanId | client.tableReservations |
| Room | Hotels, accommodations | Nights | checkIn, checkOut, nights, ratePerNight, guestId | client.roomReservations |
| Rental | Equipment, vehicles, spaces | Hours/Minutes | startAt, endAt, tierId, payment | client.rentalReservations |
How it fits together
The catalog separates bookable concepts from physical inventory, and reservation records from physical assignment. A category groups resources; each resource is a bookable type with physical instances; reservations are booked against three resource types.
- A resource defines a bookable type (a table type, room type, or rental product).
- A resource instance is a physical unit that can be assigned, blocked, cleaned, or taken out of service.
- A reservation record captures customer intent and commercial state.
- Settings define location-level behavior; slot queries generate availability.
How a reservation works
Availability comes from real schedules and resource state, so customers only book genuinely open times. A reservation then moves through its lifecycle — slightly different per type.
Why it matters
- For inventory — model a resource type once and stock it with physical instances; availability reflects real instance state (occupied, cleaning, maintenance), not a guess.
- For the booking — slot queries return only genuinely open times, and each reservation type captures the right fields (party size, nights and nightly rate, pickup/return and deposit).
- For operations — per-location settings, maintenance blocks, and tier/deposit rules mean the catalog mirrors how each site actually runs.
Status models
| Enum | Values |
|---|---|
| ReservationStatus (table/room) | pending, confirmed, seated, checked_in, completed, cancelled, no_show |
| RentalReservationStatus | upcoming, pickup_soon, out, returned, overdue, cancelled |
| PaymentStatus (room) | pending, paid, partial, failed, refunded |
| DepositStatus (rental) | pending, paid, returned, forfeited |
| ResourceInstance status | available, reserved, occupied, maintenance, cleaning, out_of_service |
SDK parity matrix
This reflects what the SDK example guides demonstrate for each language.
In TypeScript, reservations are split into tableReservations, roomReservations, and rentalReservations. In Python, a single client.reservations resource handles all types, discriminated by reservation_type, and client.reservation_resources manages bookable resources.
| Area | Operations | TypeScript | Python |
|---|---|---|---|
| Resources | create | ✓ | ✓ |
| Resources | get, get by type, update, batch | — | ✓ |
| Resource categories & instances | CRUD | ✓ | — |
| Reservations | create (table, room) | ✓ | ✓ |
| Reservations | get, get by customer, get by resource, update, update status, reschedule | ✓ (per type) | ✓ (unified) |
| Rental reservations | create, slot query, operations | ✓ | — |
| Floor plans, slot queries | create, query | ✓ | — |
| Settings & maintenance | settings, blocks | ✓ | — |
Pages
- Resources & instances — define bookable types and physical units
- Table reservations — floor plans and dining bookings
- Room reservations — lodging stays with nightly rates
- Rental reservations — equipment and vehicle rentals
- Settings & operations — per-location rules and maintenance blocks
- Quickstart — an end-to-end reservation flow