Booking page links

Every Doorloom brand site has a booking page that takes a direct booking end to end. Its whole state lives in the query string, so you can link into it with the dates, properties, guests and meal plans already chosen — from a button on the site you run, a WhatsApp message or an ad.

This is a URL contract, not an API. You build a link; the guest's browser does the rest. There is nothing to authenticate, no key to hold and no server-to-server call, which makes it the right tool for a Book now button and the wrong one for anything your own code needs to do unattended.

Where the page lives

It is /book on the brand's own host. Both of a brand's hosts serve it, so either spelling works and you can use whichever one the host publishes:

text

https://villas.doorloom.com/book        <- Doorloom subdomain
https://villasbythebay.in/book          <- the brand's custom domain

A www. prefix on a custom domain resolves to the same page. There is no booking page on doorloom.com itself — the page only exists in the context of one brand, because the brand decides which properties are bookable and who takes the money.

Check two things before you ship links

The page must exist for that brand. /book returns 404 unless the brand, or at least one of its properties, is configured to accept guest payments. A brand still taking enquiries only has no booking page at all, and a link into it is a hard 404 rather than a degraded page. Load /book once before you wire up a button.

The property must be linkable. The page offers the properties that the brand owner owns and that are not archived. A property the host merely cohosts for someone else is not among them, and neither is an archived one. Naming either in a link is not an error — that part of the link is simply ignored, and the guest lands on the page with the rest of the trip intact.

What a link looks like

Dates, then one stay parameter per property. Here, three nights for four adults and two children at one villa, with breakfast:

text

https://villas.doorloom.com/book?checkin=2026-08-14&checkout=2026-08-17&stay=villa-alto:4.2:CP

The identifier in a stay is the property's slug — the same one that appears in its page URL, /p/villa-alto. That is the single thing you need to look up per property; everything else in the link is a date or a number. The parameter reference has the full grammar, the multi-unit and multi-property forms, and the meal-plan keys.

Nothing in the link is trusted

This is the property that makes the contract safe to hand out. The server renders none of these parameters: the page reads them in the browser, and every figure a guest sees comes from a fresh price quote that Doorloom calculates from the host's own calendar, inventory and rules. A link cannot set a price, a discount or an availability.

So the failure mode of a wrong link is never a wrong charge — it is a different trip from the one you meant. Values outside what a property allows are clamped, and anything unrecognised is dropped. Each adjustment is written straight back into the address bar, which gives you a simple way to test a link: open it and read the URL you end up with. If it matches what you sent, nothing was adjusted.

Dates alone are a perfectly good link

You do not have to name a property. /book?checkin=…&checkout=… opens the page on those dates with an empty cart and lets the guest pick, which is often the better landing page for a campaign that is about a weekend rather than a villa.

Your tracking parameters survive

The page rewrites only the parameters it owns. Everything else in the query string — utm_source, utm_medium, utm_campaign, gclid, fbclid, your own keys — is carried through untouched as the guest edits the cart, and is still in the URL at the moment they pay. You can attribute a booking to the campaign that produced it without doing anything special.

These links are not for SEO

The booking page is deliberately kept out of search: it is noindex, nofollow, and the brand's robots.txt disallows /book. It is a checkout, and a checkout with a different URL per cart state is not something to have crawled.

Use these links where you control the click — buttons, email, WhatsApp, paid ads. For pages that should rank, link to the search page or a property page instead; both are indexable and both accept the same dates and guest counts. See search and property links.

What this is not

There is no public checkout API

The booking page talks to JSON endpoints on its own origin, and you may see them in your browser's network tab. They are not a public interface: they are session-bound web routes that require a CSRF token issued to that page, so they cannot be called from your own site or server, and they are free to change without notice.

If your code needs to create or manage bookings directly, that is what the Brand Integration API is for — see create a booking. It is a versioned contract, it is authenticated, and it will not move under you.

Choosing between them is usually quick:

Booking page links when a guest is going to book. They click, they see live prices, they pay the host. No credentials involved.
The Brand Integration API when your system holds the booking — a PMS, a channel manager, a checkout you built. You create the booking server to server and you set its price.