Door codes that appear when they should

How it works

Add a code section to your guide and give it a reveal rule — most hosts pick 24 hours before check-in. From then on you do nothing per booking: every stay’s link applies the rule to its own dates.

The part that matters is where the gating happens. The guest’s page is assembled on our servers for each visit. Before the reveal moment, the server leaves the code out of the page entirely — what travels to the phone is a card saying what the section is and when it opens. There is no hidden text to uncover, no locked element a clever guest can inspect.

This is not how most tools do it. The common shortcut is to send the whole guide to the browser and hide the sensitive parts with styling — which means the code is sitting in the page source days early, for anyone who knows where to look.

You can verify our version yourself. Open a guest link before the reveal time and view the page source:

<!-- the guide, the day before check-in -->
<section id="door-code">
  Door code — unlocks Friday at 15:00
</section>
<!-- the code is not in this page. It has not been sent yet. -->

Search the source for your code. It is not there, because it never left the server.

What the guest sees

Before the reveal, the door code section sits in the guide with a quiet badge: a name, and the time it opens — Unlocks Friday at 15:00. Guests know the code is coming and when, which is exactly enough.

At the reveal moment the section simply becomes a normal part of the guide: the code in large clear digits, with whatever you wrote around it — which keypad, which door, the trick with the handle. After check-out the link expires and takes the code with it.

What changing the code looks like

Rotate your codes whenever you like. Edit the section once; every active guide shows the new code on its next open. There are no stale copies, because there were never any copies — each visit reads the current guide from the server. The WhatsApp message from March cannot make that claim.