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 Account Manager to verify - 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 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.

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.