Fixed hour
Exact departures during the day, like a tour at 10:00 and another at 15:00. The customer picks a specific time, not a range.
Availability
Availability is calculated. Never generated.
No "generate calendar" button someone forgets to click, no thousands of rows created just in case. Every date a customer sees resolves on the spot, from rules, whether you ask about tomorrow or ten years out.
- On the fly Every date is computed at query time, never pre-generated
- 3 Ways to sell time: fixed hour, time window, or a full open day
- Its own timezone The booking cutoff is computed where the experience happens, not on the server
Three ways to sell time. Two ways to repeat it.
One engine decides both when someone enters and how often that repeats, with no separate configuration needed for each case.
Time window
Several arrival windows per day, like "8:00 to 11:00" or "13:00 to 18:00". The customer picks the window, not an exact minute.
Full day
No time slots at all: the product is open the whole day, like general admission to a museum. The customer books the date, not an hour.
Recurring or fixed dates
A weekly schedule that repeats indefinitely, or a short list of exact dates for something specific, like a concert or a one-off show.
How it resolves
How a date gets decided as open
Five steps, in this exact order, every single time someone queries the calendar.
- 1
Calendar exception
Is there an exception configured for this exact day? A one-off closure or special hours always beats any recurring rule.
- 2
The most specific recurring rule
If there's no exception, whichever rule matches that day of the week applies. If two rules overlap (a general one and a seasonal one), the more specific one wins: the one with its own start and end date.
- 3
Time slots
The rule or exception returns its hours, interpreted according to the option's availability mode: fixed hour, window, or full day.
- 4
Booking cutoff
Each slot is checked against the configured cutoff, computed in the product's own timezone, never the server's. If that instant has already passed, the slot stops being offered even if there are hours left until that local time.
- 5
Booking horizon
If the option has a booking horizon (say, 90 days), anything past that limit is never even computed.
The API, as it is
What checkout sees is what you see here
The same query that resolves the calendar also resolves the final price, taxes included, and the remaining capacity for each slot. There's no separate unconfirmed 'from' price: this is exactly what checkout uses to charge.
GET /api/v1/products/observation-deck/calendar
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
{
"date": "2026-08-14",
"is_open": true,
"min_price_display": "€42.00",
"slots": [
{
"start_time": "18:00",
"end_time": null,
"is_open": true,
"remaining_capacity": 12,
"min_price_display": "€42.00"
},
{
"start_time": "20:30",
"end_time": null,
"is_open": true,
"remaining_capacity": 4,
"min_price_display": "€48.00"
}
]
}200 Availability resolved
The detail almost nobody tests
A concert can't lose its own date
Dates are always compared as plain calendar strings ("2026-08-14"), never as absolute instants. Compared as instants, a "fixed dates" option (a concert, say) could fail to resolve as bookable on its own exact date, depending on which side of the UTC offset the product landed on. We found that case, documented it, and closed it with a dedicated test suite. A product with no time slots at all (a full open day) still gets a real cutoff too: its limit anchors to the end of the local day, not to some arbitrary instant.
Frequently asked questions
The more specific one wins. If there's a general rule for every Tuesday and a seasonal one that also covers that Tuesday with its own start and end date, the seasonal one applies. Rules are ordered by specificity before resolving, so it doesn't matter which was created first.
Against the exact time of the slot, in the product's own timezone. An 8:00 slot with a two-hour cutoff stops showing at 6:01, computed where the experience happens, not where the server sits. For a product with no time slots, the cutoff anchors to the end of the local day.
No. Nothing is ever pre-generated or materialized. Every query computes the dates and slots on the spot, from whatever rules and exceptions are in force, so a schedule configured today works exactly the same in ten years, with zero maintenance.
Yes. The same query resolves the calendar, the final price with taxes applied, and the remaining capacity per slot, using the worst case among ticket types that share capacity. It's exactly what checkout uses to charge, not a separate estimate.
Yes, with a calendar exception. A single date can be closed, like a holiday, or given different hours, like a shorter schedule on New Year's Eve, without touching the recurring rule that governs the rest of the year.
More bookings. More channels. The same calm.
Tiqory keeps availability, pricing, payments and access working together as your operation grows. Tell us where you are headed; we’ll show you how to get there without starting over.