Enquiries Channel manager Bookings Your website Booking engine Pricing Log in Sign up
v2026-09

Booking page parameters

Every parameter the booking page accepts, its exact format, and what it does with a value it cannot use. Nothing here is authenticated and nothing here sets a price — see booking page links for how the contract works before using this as a lookup table.

The canonical link

Dates once, then one stay parameter per property. This is three nights across two properties — four adults and two children in one villa with breakfast, and two units of another with no meals:

text 
https://villas.doorloom.com/book
  ?checkin=2026-08-14
  &checkout=2026-08-17
  &stay=villa-alto:4.2:CP
  &stay=casa-mar:2.0-2.1:EP

Line breaks are for reading only — send it as one line. Emit parameters in any order.

Parameters

Field Type Required Description
checkin date Required with checkout Arrival date as YYYY-MM-DD.
checkout date Required with checkin Departure date as YYYY-MM-DD. Must be after checkin.
stay string, repeatable Optional One property and its guests. Repeat it once per property, up to 10 properties. Grammar below.
add string Optional Deprecated single-property form, kept working for old links. Use stay.
adults integer Optional Deprecated. Only read alongside add.
children integer Optional Deprecated. Only read alongside add.

Any other parameter you include is preserved and ignored, which is what makes utm_source and friends safe to append.

checkin and checkout

Both are plain calendar dates in YYYY-MM-DD. The format is matched strictly — no other separator, no two-digit year, no time component, no timezone offset. Three rules apply, and breaking any one of them clears both dates rather than guessing:

  • Both or neither. A lone checkin prices nothing, so it is discarded along with its partner.
  • Departure after arrival. Equal dates are rejected too — the page books nights, not days.
  • Arrival not in the past.

Today is the guest's today, not India's

Whether a date counts as past is judged against the clock on the guest's own device. A link for tomorrow or later is unambiguous. A link for today will read as past for anyone whose local date has not caught up with India yet, and they will see the page with no dates selected. For a campaign that runs over a date boundary, start the stay tomorrow.

A stay may be at most 730 nights. Per-property rules — a minimum stay, a maximum stay, how much notice is required — are set by the host and are checked when the page prices the trip, not when it reads the URL. A link that breaks one of them opens normally and shows the guest the specific reason, for example that the minimum stay is two nights. There is no way to discover those rules from a link, so if you are generating many, expect some to land on a message.

The stay parameter

stay describes one property and exactly how its guests are distributed. It repeats — once per property — and is never comma-joined:

text 
stay=<slug>:<adults>.<children>[-<adults>.<children>...]:<meal>

Three colon-separated fields:

Field Type Required Description
slug string Required The property slug, the same one in its page URL at /p/{slug}. Percent-encode it; leave the colons literal.
guests string Required One adults.children pair per unit, joined by -. A dot separates the two counts, a hyphen separates units.
meal string Required A meal-plan key: EP, CP, MP or AP.

The guests field is where the shape of the booking is expressed. One dotted pair per unit, so the number of pairs is the number of units being booked:

text 
stay=villa-alto:4.2:CP           one unit:    4 adults, 2 children
stay=villa-alto:2.0-2.1:CP       two units:   2 adults in one, 2 adults + 1 child in the other
stay=villa-alto:2.0-2.0-2.0:EP   three units: 2 adults in each

That is why the counts are per unit rather than per booking: two rooms holding four people each is a different price from one room holding eight, and the link has to be able to say which. If the property is a whole villa with a single unit, there is only ever one pair.

The token is parsed from the right, so a slug that itself contains a colon still resolves correctly. You never need to escape the separators — percent-encode the slug alone and leave the : and - characters as they are, which also keeps the link readable when it is pasted into a chat.

Meal plans

The meal key is part of the token because it changes the price. A link without it would not reproduce the trip that was quoted.

Field Type Description
EP European Plan Room only, no meals.
CP Continental Plan Breakfast included.
MP Modified American Plan Breakfast and one more meal.
AP American Plan All meals included.

A host enables the plans they actually offer, per property, so not every key is valid everywhere. A key the property does not offer falls back to the cheapest plan it does offer.

Leaving the meal key off is not the same as EP

EP is a real plan a host can switch off, which is how a property makes a meal plan mandatory. On such a property there is no room-only option at all, so a link asking for EP — or an older link that implies it — is priced on the cheapest plan that is offered, meals included. If the price matters in your copy, name the plan explicitly and check it against what the host has enabled.

Older link formats

Two earlier formats are still accepted and always will be: links live in WhatsApp threads for years. Both are rewritten into the canonical form the moment the page loads, so a guest who re-shares an old link passes on a current one.

text 
stay=<slug>:<adults>:<children>:<units>:<meal>   per-stay counts, expanded to identical units
stay=<slug>                                      one unit, 2 adults, cheapest plan
add=<slug>&adults=2&children=0                   the oldest form, one unit

In the five-field form the counts apply to every unit, which is exactly why it was replaced: it cannot express two units with different occupancies. Trailing fields may be omitted, and anything missing defaults to two adults, no children, one unit and the cheapest plan. Recognise these when you meet them; emit the canonical form.

What happens to a link that does not fit

The page never shows an error for a parameter. It takes what it can use, adjusts what it cannot, and writes the result back into the address bar.

Adjustments

Field Type Description
Bad or past dates both cleared Wrong format, checkout not after checkin, a date in the past, or only one of the two. The page opens with no dates selected.
Unknown slug that stay dropped Not one of this brand owner's bookable properties — misspelt, archived, cohosted, or belonging to another brand. Other stays in the link are unaffected.
Repeated slug deduplicated The first occurrence wins. Book more units of one property by adding pairs to its guests field, not by repeating the parameter.
More than 10 properties truncated to 10 The limit counts properties actually added to the cart, in the order you wrote them. A duplicate or unknown slug is discarded first and does not use up one of the ten.
More units than the property has truncated Extra pairs are dropped to the number of units that exist.
Children above the limit clamped Capped at one below the property's maximum occupancy, so a unit always has room for an adult.
Adults above the limit clamped Capped at the maximum occupancy less that unit's children.
Unknown or unavailable meal key cheapest enabled plan See meal plans above.

Availability is not in that list. A link for dates that are booked or blocked opens with those dates selected and tells the guest what is wrong — for example that only one unit is left. Silently wiping dates somebody shared is worse than showing them why they do not work.

Testing a link

Because every adjustment is written back, the address bar after the page loads is a complete report on your link. Open it and compare:

  • The URL came back unchanged — apart from reordering and the canonical stay form — and nothing was adjusted.
  • A stay is missing — that slug is not bookable on this brand. Check the spelling against the property page URL, and that the host owns rather than cohosts it.
  • The numbers came back smaller — you exceeded occupancy or the unit count.
  • The dates are gone — format, ordering, or a date that is already past where you are testing from.
  • The meal key changed — that plan is not enabled on that property.

It is worth doing this once per property when you first wire up links, and again if the host tells you they have changed their meal plans or occupancy.

Recipes

All of these are single lines, wrapped here to stay readable.

One villa, one unit, a family of six with breakfast text 
/book?checkin=2026-12-24&checkout=2026-12-27&stay=villa-alto:4.2:CP
One property, two units with different occupancies text 
/book?checkin=2026-12-24&checkout=2026-12-27&stay=casa-mar:2.0-3.1:MP
Two properties in one cart, one booking flow text 
/book?checkin=2026-12-24&checkout=2026-12-27
  &stay=villa-alto:4.2:CP
  &stay=casa-mar:2.0:EP
A weekend campaign — dates only, guest chooses the property text 
/book?checkin=2027-01-15&checkout=2027-01-17
One property, guest chooses the dates text 
/book?stay=villa-alto:2.0:EP
With campaign attribution, which is carried through to payment text 
/book?checkin=2026-12-24&checkout=2026-12-27&stay=villa-alto:4.2:CP
  &utm_source=instagram&utm_medium=paid&utm_campaign=newyear26

A slug needing encoding is the only case that is not copy-paste. Percent-encode the slug and nothing else:

Building a link in JavaScript js 
const base = 'https://villas.doorloom.com/book';
const stay = `${encodeURIComponent(slug)}:${adults}.${children}:${meal}`;

const url = `${base}?checkin=${checkin}&checkout=${checkout}&stay=${stay}`;

Do not build the query string with a URL-encoding helper that escapes the whole stay value: the colons and hyphens are structure, and encoding them turns a readable link into an unreadable one. They need no escaping.

Something unclear or wrong on this page? Write to [email protected] and tell us which page — we would rather fix the doc than answer the ticket twice.