Guest-facing links

Five surfaces face people who have no account: three private token links, the guest app, and your public booking website. None requires a login in the usual sense, and all of them share one security posture, described at the end.

Link	Shape	Who holds it	Lifetime	How it dies
Quote link	/q/{token}	The guest with a live quote	No time limit	Revoked when the quote is edited or re-quoted
ID upload link	/id/{token}	A guest asked for identity documents	72 hours	Expiry, revocation, or the check being decided
Proposal link	/p/{token}	An investment prospect	30 days by default (settable per link)	Expiry, revocation, or the proposal being withdrawn
Guest app	/g/{appId}	An in-stay (or recently departed) guest	Session lasts through the stay; sign-in stays possible up to 14 days after checkout	The window closing
Booking website	/s/{siteSlug}	The public	While published	Unpublishing or disabling the site

The quote link - /q/{token}

The itemized quotation with your letterhead and payment details, plus a PDF version. It is also a write surface: the guest uploads their payment proof here, which lands as a proof_received claim for your team to verify (an Account Manager, Booking Manager or Point of Contact) - the guest never states an amount. Editing or re-quoting the inquiry revokes the old link and mints a new one, so a guest can never be holding a page that shows a superseded price. If your workspace has turned on the quote-approval policy, releasing a link first parks in the Approvals queue.

The ID upload link - /id/{token}

A private, expiring page where the guest uploads identity documents (ID card front and back, or passport), picks their nationality, and types the document number. Expiry - 72 hours - is enforced in the database resolver itself, so no code path can serve an expired link. The page discloses nothing sensitive: which stay this is for and what to upload, never a number already on file or another guest’s check. Uploading only moves the check to received - verification remains a human decision on your side.

The proposal link - /p/{token}

An investor term sheet. Revocable at any time from Partners → Proposals, and expiring (30 days unless you set otherwise when sharing). A withdrawn proposal kills the link even before it expires.

The guest app - /g/{appId}

The in-stay progressive web app: reservation details, the self check-in wizard, door opening, Wi-Fi, house information, and the message thread. A guest signs in with their booking reference code plus any one confirming detail - their name, their check-in or check-out date, or their phone number. The reference code is the secret; the second detail confirms the stay is theirs. Cancelled and no-show bookings can never sign in; a departed guest can still reach receipts and messages for up to 14 days. The same app is also served inside your booking website at /s/{siteSlug}/stay/…, so a guest who installed your site keeps everything in one frame.

The booking website - /s/{siteSlug}

The one deliberately public surface: your direct-booking site, indexable and crawlable once published. Everything on it was published on purpose - the resolver refuses anything else, and publishing is restricted to Owner/Admin seats precisely because it makes content world-readable. Pages are cached briefly for speed, but the search and booking steps always run live so availability is never stale.

Before you publish, people signed in to your workspace can see the site as a draft with Preview your site on Channels → Booking website; guests get the not-found page until it is published.

The shared security posture

Every failure is the same 404

A malformed token, an unknown token, a revoked link, an expired link, a decided check, a withdrawn proposal, an unpublished site - every one of them shows the identical plain not-found page. No error ever distinguishes “never existed” from “existed and was revoked,” so a prober can’t learn which tokens are real or whose data sits behind them.

The three private token pages are also marked noindex/nofollow and never cached, so a quotation naming a guest and a price can’t end up in a search engine - while the booking site, the one page meant to be found, is indexable by design.