Booking rules reference | LiteHQ documentation

Two things decide whether a booking can be made: how long it has to be, and whether the facility is open to the person asking. That is the whole model.

There is no rule engine. LiteHQ does not evaluate a list of prioritised rules, and there is no way to express “deny this room on this date” as a rule. If you need a room closed for a day, you change the facility's availability, which is covered below.

This page was rewritten on 2026-08-07. It previously described a rules engine with JSON rule documents, priorities and blackout dates. That engine does not exist and never did, so the page now covers only what the product actually enforces. Anything you configured on the strength of the old page was not doing what it said.

Section 1

Minimum booking duration

One setting, split by whether the person is a member

There are two minimum durations, one applied to members and one applied to everybody else. The booking wizard picks between them based on whether the person booking is a member. They are fixed in the product, not configured per facility.

The minimum is the fewest minutes a booking may run for, and it does two things in the wizard. It removes any shorter duration from the dropdown, and if the wizard opened with a shorter duration selected it raises it to the minimum rather than showing an error the person has not caused yet.

The two values

Members: 30 minutes.
Non-members (anyone booking through the public link): 2 hours.

This member and non-member split is the only per-audience mechanism booking rules have, and it is one boolean: does this person hold an active membership at all. Both the minimum duration above and the member price on a rate read that same boolean. Neither reads which plan the person is on, so no booking rule and no booking price distinguishes a premium member from a standard one.

Plans are not interchangeable everywhere, though, and it is worth being precise about where they differ. A membership points at a rate plan, and that plan sets the monthly token allowance the member's company is refreshed to on the 1st. That is a spending allowance, not a booking rule: it changes how much a member can consume, never what they are allowed to book or for how long.

There is no maximum duration. A maximum can be stored, and the admin UI will show it back to you, but nothing enforces it at booking time, so a person can book for longer than the maximum you set. See Settings that are not applied below.

Section 2

Facility availability

The gate that actually turns bookings off

This is what to reach for when you need a room closed. It is enforced on the server: a facility that fails any of these checks returns a 404 from the booking wizard, so a shared or guessed URL does not get around it.

Per-facility switches

Takes online bookings. Turn this off and the facility is internal: it takes no online bookings from anyone.
Publicly listed and privacy. A facility is reachable from the public booking link only when it is publicly listed and its privacy is public. Privacy has three values, and the third one is easy to miss. Members is hidden from the public link but still bookable in the app by a signed-in member. Limited is admin only: it is filtered out of the member-facing lists and refused by the booking gate, so only an operator booking on someone's behalf can put a booking on it.
Status. Anything other than active takes the facility offline immediately. This is the toggle in the facilities list.

The availability window

A facility can carry a start date, an end date, or both. Compared against today's date, they produce three non-live states:

Scheduled: the start date is in the future, so it is not bookable yet.
Ended: the end date has passed.
Inactive: status was set to something other than active.

Status wins over the window, deliberately: status is what the list toggle writes, so a manually deactivated facility reports as inactive rather than as ended. The window states are fixed by editing the dates, not by the toggle, which is why the toggle refuses them.

Closing a room for one day. There is no blackout-date feature. The closest thing is the availability window, and it is a single range rather than a set of dates, so it handles “this room opens in March” or “this room retires in June” but not “closed every public holiday”. For a one-off closure today, set status to inactive and set it back afterwards.

Section 3

Settings that are stored but not applied

Read this before you rely on anything in the booking settings form

The booking settings form saves more than the product enforces. These values persist, and reopening the form shows them back to you, which reads as confirmation that they took effect. They did not.

None of the following are checked when a booking is made:

Maximum booking duration
Buffer time between bookings
How far ahead bookings may be made
Requiring approval for a booking
Requiring check-in
Restricting bookings to credits or tokens
Auto-cancelling a booking that is not checked into
Booking reminders and how long before to send them
Limits on start times
Recurring-booking limits and how far they may span

Some of these are read back to compose the summary sentence shown beside a rate, so you may see one quoted in the admin UI. Being printed in a sentence is not the same as being enforced at booking time, and none of them are.

Do not use these as a control. If you need to stop a booking from happening, the facility availability settings in Section 2 are the only thing that will do it. Setting a maximum duration or requiring approval will not.

This is tracked and the intent is to either enforce each setting or remove it. Until then this page will list them here rather than describe them as features.

Next steps