Inventory and availability
The shared model behind both reservation products: units, availability quantities, expiring holds, safe retries and bookings.
The model both products share
Hotel OS and Bus OS use the same reservations core, so availability, holds and bookings behave identically in both. Learning it once covers both products and the scoped APIs.
| Concept | Hotel meaning | Bus meaning |
|---|---|---|
| Inventory unit | A room type at a property | A seat pool on a trip |
| Availability slot | That room type on a date | That trip on its departure |
| Hold | A short-lived claim on units while a booking is being completed | Same |
| Booking | A confirmed hold | Same |
What an availability slot tracks
A slot is not a single number. It separates the quantities an operator needs to reason about independently:
| Quantity | Meaning |
|---|---|
| Total | The full capacity of the unit for that slot |
| Booked | Confirmed and sold |
| Held | Claimed by an in-progress booking, not yet confirmed |
| Safety buffer | Capacity deliberately withheld from sale |
| Available to sell | What a channel may actually take right now |
Available to sell is the number a channel should read. Because the buffer is its own quantity, an operator can hold back capacity without editing total capacity and losing the real number.
Holds expire
A hold reserves capacity for a limited time and then releases itself. An abandoned checkout therefore returns its capacity without anyone intervening, and a slow payment cannot quietly hold a room or a seat indefinitely.
Holds carry the channel or source that created them, so an operator can see where in-progress demand is coming from.
Safe retries
Hold and booking requests are idempotent: a retried or duplicated request produces one hold and one booking, not two. This matters most for API callers and unreliable networks at a counter, where a timeout should never mean a double booking.
The sequence
- Read availability for the unit and date or trip.
- Place a hold for the requested quantity, with an idempotency key.
- Complete the customer-facing step.
- Confirm the hold into a booking, or let it expire.
Never treat step 1 as a reservation. Availability is a read; only a hold protects capacity.
Configured per implementation
Cancellation and refund workflows, channel connectors, settlement and outbound webhooks are configured per implementation rather than shipped as one fixed shape. Confirm the exact scope during onboarding rather than assuming parity with every feature of a full PMS or bus GDS.