Custom weekday percentages change the nightly rate. Minimum stays and check-in/out restrictions change stay eligibility instead. Keep these jobs separate when deciding why a date's price or bookability changed.
Starting from $200 after model effects, custom Friday +5% and Saturday +10% create the following prices.
The chart holds the price after model effects at $200 to isolate your custom policy. In a live response, Friday and Saturday can already differ before this extra percentage runs. A custom +10% Saturday adjustment does not replace the model's Saturday factor.
For example, a $200 base with only a modeled Saturday +5% becomes $210. Your additional Saturday +10% then produces $231, not $220.
Illustrative calendar: June 12–17, 2026. Calculation date June 13; $200 per night after model effects.
The one-night gap is not eligible with a two-night minimum. The two-night gap can still qualify if arrival and departure permissions allow it. The minimum stay does not itself add or subtract money.
| Control | Directly changes the nightly price? | Can change gap eligibility? |
|---|---|---|
| Custom day_of_week | Yes | Not by itself |
| min_stay | No | Yes |
| check_in_out | No | Yes |
| length_of_stay | Not currently | No current effect |
A configured weekly or monthly tier currently leaves the daily price unchanged.
A valid request containing a weekly discount tier is not proof that the discount was applied. The current API accepts and validates length_of_stay but does not calculate a discounted stay quote from it. If you need a booking total, calculate it in a workflow that explicitly supports those discounts.
The JSON below is an addition to this complete Calendar Prices request. Merge fields into one request; do not send a rule fragment by itself.
{
"location": {
"latitude": 25.7907,
"longitude": -80.13
},
"currency": "USD",
"base_price": 200
}
All worked prices use USD and assume a $200 price after model effects, with no other adjustments unless stated. They demonstrate arithmetic, not live forecasts.
{
"pricing_rules": {
"day_of_week": {
"mode": "custom",
"settings": {
"adjustment_percent": {
"monday": 0, "tuesday": 0, "wednesday": 0, "thursday": 0,
"friday": 5, "saturday": 10, "sunday": 0
}
}
}
}
}
Friday adds 5% (200 → 210); Saturday adds 10% (200 → 220). This multiplies the running price in addition to AirROI's modeled weekday effect and after the automatic-rule adjustments. All seven lowercase weekday keys are required, with values from −75 through +500. Percentages throughout the request accept at most two decimal places.
This custom policy allows Friday or Saturday check-in, while allowing checkout on every weekday.
| Stay-date weekday | Check-in | Check-out |
|---|---|---|
| Monday | × Not allowed | ✓ Allowed |
| Tuesday | × Not allowed | ✓ Allowed |
| Wednesday | × Not allowed | ✓ Allowed |
| Thursday | × Not allowed | ✓ Allowed |
| Friday | ✓ Allowed | ✓ Allowed |
| Saturday | ✓ Allowed | ✓ Allowed |
| Sunday | × Not allowed | ✓ Allowed |
Read arrival and departure permissions independently. A Sunday row with check_in_allowed false and check_out_allowed true prohibits starting a stay that day but permits ending one. Those flags alone do not mean the night is available; consult your live calendar too.
{
"stay_rules": {
"min_stay": {"mode": "custom", "settings": {"min_nights": 2}},
"check_in_out": {
"mode": "custom",
"settings": {
"allowed_check_in_days": ["friday", "saturday"],
"allowed_check_out_days": ["monday", "tuesday", "wednesday", "thursday", "friday", "saturday", "sunday"]
}
}
}
}
A Saturday row includes min_stay: 2, check_in_allowed: true, and
check_out_allowed: true. Sunday has check_in_allowed: false.
min_nights accepts 1–365. Both weekday lists require at least one unique,
lowercase weekday. These fields appear only when the corresponding custom
stay rule is enabled; calendar-row restrictions are not echoed in the output.
To affect actual bookings, these restrictions must be supported and enforced by your channel manager, PMS, or OTA integration. AirROI returns them but does not publish or enforce them on booking channels.
Stay rules do not directly change the nightly price. They can make a gap ineligible for a gap-day adjustment. When testing a gap, configured custom stay rules take precedence over the calendar-row restrictions.
| Date in the example | Minimum stay | Check-in allowed | Check-out allowed |
|---|---|---|---|
| Saturday, June 13, 2026 | 2 nights | true | true |
| Sunday, June 14, 2026 | 2 nights | false | true |
These output fields appear only when the corresponding custom stay rule is enabled. A calendar row with min_stay: 3 does not, by itself, cause that restriction to appear in the recommendation response.
{
"stay_rules": {
"length_of_stay": {
"mode": "custom",
"settings": [
{"min_nights": 7, "adjustment_percent": -10},
{"min_nights": 28, "adjustment_percent": -20}
]
}
}
}
These tiers express intended weekly and monthly discounts, but this rule
currently changes no price or output field: 200 remains 200.
min_nights must increase strictly (1–365); discounts accept −75 through 0.
Do not rely on these settings to produce discounted stay quotes.
Configure the discounts separately in a supporting booking integration, which can
evaluate the guest's selected arrival/departure dates and total stay length.
A custom Saturday +10% is applied after the automatic-rule adjustments, in addition to any modeled Saturday effect. Meanwhile, a two-night minimum can make a one-night gap ineligible for a gap adjustment. These are different reasons for the final price to differ from a simple standalone example.
Stay ahead of the curve
Join our newsletter for exclusive insights and updates. No spam ever.