> ## Documentation Index > Fetch the complete documentation index at: https://www.twicecommerce.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # How to set purchase and booking limits > Constrain how short, how long, and how late a customer can book — minimum and maximum duration, the duration increment, and the order deadline. catalog/listings → Limits Four settings on the **Limits** tab decide what a customer is allowed to book: the shortest duration, the longest, the steps in between, and how late they can order. They are four fields and take a minute to fill in. What takes longer is knowing that two of them behave differently depending on how the listing is priced — and that the fourth one is the only setting in TWICE that stops a too-soon booking from appearing on the storefront at all. ## Prerequisites **Required permission:** `catalog:listing_limits`. All four system roles — Owner, Admin, Manager and Member — hold every operation on this tab. **Know how the listing is priced before you set duration limits.** The three duration settings behave differently on the two pricing models: * **Fixed-duration pricing** (a row that says "1 day", "1 week"): min and max **filter which options the storefront offers**. The increment does nothing — a fixed row's duration comes from the row. * **Rate-based (dynamic) pricing** (the customer picks any span): all three are **enforced by the server**, at cart-add and again at order creation. Same fields, two different jobs. If you set a limit and nothing appears to change, this is usually why. ## The Walkthrough Open the listing from **Catalog → Listings** and go to the **Limits** tab. The **Booking limits** card holds all four settings — *configure the shortest and longest booking duration allowed*. Every field starts at **No limit**, and every field can go back to it. Clearing the number (or typing `0`) restores No limit; you do not need a separate "off" control. **Minimum booking duration** is a number plus a unit — seconds, minutes, hours, days, weeks or months. On a rate-based listing this is a hard floor: a shorter span is rejected with a 400 at checkout. On a fixed-duration listing it removes the shorter price rows from the storefront, so a customer never sees them. One consequence worth knowing on fixed pricing: the **"from" price shown on the listing is the cheapest *bookable* duration**, not the cheapest row on the price table. Raising the minimum raises the advertised price. Units are calendar-aware. A "1 month" minimum is satisfied by a 28-day February, because the bound is computed by adding a calendar month to the start rather than by converting to seconds. **Maximum booking duration** works the same way in the other direction, and it is the setting that protects your fleet from a booking that quietly runs for a year. Set it even where you do not expect long rentals. An unbounded maximum on a rate-based listing means the storefront will happily accept any end date the customer picks. **Booking duration increment** constrains selectable durations to whole multiples of a unit. A 1-week increment means 1, 2 or 3 whole weeks — never ten days. **This applies to rate-based pricing only.** A fixed-duration row derives its duration from the row itself, so the increment has no effect on it. Setting an increment on a listing that only has fixed rows does nothing, which is a quiet way to believe you have configured something you have not. The increment composes with min and max rather than overriding them: a selectable duration has to be both a whole multiple of the increment **and** inside the min/max range. A 1-week increment with a 10-day maximum allows exactly one option — one week. **Orders must be placed at latest** is the lead time. It has three settings: * **No deadline** — order any time up to the start. * **A set time before** — a fixed offset: a value, a unit (minutes, hours or days), *before start*. "2 hours before start" means a 14:00 booking must be ordered by 12:00. * **By time of day** — a wall-clock cutoff on an earlier day: *N* **days before, by** `18:00`. A Wednesday booking must be ordered by 18:00 on Tuesday. `0` days before means by that time on the start day itself. The cutoff resolves in the **service location's timezone**, not the customer's and not yours. Unlike the duration settings, the deadline applies to fixed and rate-based bookings alike — it gates the *start time*, not the duration. Save, then open the listing on the storefront. This is the step that catches mistakes, because the two pricing models fail differently and only one of them fails loudly. On a fixed-duration listing a wrong limit shows up as options that are missing or options that should not be there — no error, just a picker that offers the wrong set. ## How do I know it worked? Open the listing on the storefront and check each setting where it shows up: * **Duration limits, fixed pricing** — the duration picker offers only rows inside the range, and the "from" price matches the cheapest one still offered. * **Duration limits, rate-based pricing** — an out-of-range end date is refused at checkout rather than hidden. * **Increment** — the return-date and return-time pickers only offer aligned options. * **Order deadline** — start times past the cutoff are marked unavailable on the calendar. A customer who already had the item in their cart sees a notice that the order deadline has passed. Staff are exempt from the order deadline: admin order creation skips it deliberately, so a phone booking can still be taken after the storefront has closed that slot. Checking the deadline from admin will therefore always succeed — the storefront is the only place it is visible. ## Troubleshooting / Common Pitfalls **Cause:** the listing is priced with fixed durations. A fixed row carries its own duration, so there is nothing for the increment to constrain. **What to do:** if you need "whole weeks only" on a fixed-priced listing, that is a price-table question — offer the week rows you want bookable. The increment is a rate-based setting. **Cause:** you raised the **Minimum booking duration**. The "from" price is the cheapest bookable duration, so removing the short durations removes the cheap prices with them. **What to do:** this is working as intended. If the advertised price matters more than the floor, lower the minimum or add a cheaper row inside the allowed range. **A buffer is not an order deadline.** A stock item's buffer time in Inventory rejects a too-soon start, but it does not remove those times from the storefront calendar. The customer picks one, gets through most of the flow, and fails at checkout. **What to do:** set the **order deadline** here as well. It is the setting that makes the storefront stop offering those start times in the first place. See [Buffer times and bin locations](/docs/guides/inventory/buffer-times-and-bin-locations). **Cause:** **By time of day** resolves in the **service location's** timezone. A location in a different timezone from the one you are sitting in cuts off at its own local `18:00`, not yours. **What to do:** check the service location's timezone before reading the cutoff as wrong. If one listing is sold from locations in two timezones, the deadline resolves per location — the customer's booking is gated by the location fulfilling it. **Working as designed.** The order deadline is enforced on storefront paths only; admin order management is exempt so staff can take a late booking on the phone. **What to do:** nothing, unless you need staff blocked too — which this setting cannot do. **Cause:** the selected span violated the minimum, the maximum, or the increment. The server validates the duration at cart-add and again at order creation, and the message names which of the three failed. **What to do:** read the message rather than guessing. "Shorter than the minimum", "exceeds the maximum" and "must be a multiple of the allowed increment" are three different fields. **Correct.** A sale has no duration and no start time, so no setting on this tab constrains it. A listing sold as well as rented is limited on its bookings only. Subscriptions are gated by the order deadline, evaluated against the whole start day rather than the exact instant. **Not available.** There is no per-order quantity cap on a listing. The Limits tab holds four duration and deadline settings and nothing about quantity. **What to do:** what constrains quantity is real availability — the stock the listing's inventory rules match. If a customer must not be able to take ten of something, the limit that holds is having fewer than ten bookable. See [Listing inventory rules](/docs/guides/catalog/listing-inventory-rules). ## Next Steps The tab reference, field by field. How a deadline feeds the availability evaluation. Fixed versus rate-based — the distinction these limits turn on. The stock-side setting an order deadline complements.