Security you can trust — without the complexity
TapStay separates what a stay link can show from what a guest session can unlock. The public stay address returns only neutral presentation content — it can never return Wi-Fi credentials, access codes, the host phone number, the address or host-written operational text. Operational details are released only after the server re-validates a guest session against that property and the currently eligible stay, and sensitive codes stay masked until the check-in window opens. Provider keys and privileged database access live on the server only, never in the browser.
- Public link ≠ operational access
- Server-revalidated guest sessions
- Database-level access rules
- Provider keys stay server-side
What we protect
Four things we treat as sensitive
Your host account and properties
Every property is tied to your account. Host reads and writes are scoped to your own records at the database level, not just in the interface.
Stay access details
Wi-Fi credentials, entry codes and access instructions are treated as operational data. They are never part of the public stay page and are masked until the check-in window opens.
Platform and provider secrets
Keys for the AI Concierge and nearby-place lookups are read on the server only. They are never shipped to the browser and never exposed through a page or network response.
System integrity
Costly public endpoints carry request ceilings, responses carry conservative security headers, and guest media is served through short-lived signed links from a private bucket.
How access works
A public address, then a validated session
- 1
A guest opens the stay link
The permanent slug in the URL is an address, not a credential. On its own it returns a neutral page: the property presentation, photos and general stay framing.
- 2
The server decides what is releasable
Neutral reads go through a narrow database function that cannot return Wi-Fi credentials, the host phone, address components, coordinates, house rules, FAQ or checkout instructions. Nothing sensitive is fetched and then filtered — it is never selected.
- 3
A guest session is validated
Operational content requires a guest session token. The server re-validates that token against the property and the currently eligible stay on every single call. There is no path from “a stay exists” to operational data.
- 4
Time gating for arrival details
Before check-in, the portal runs in a limited pre-arrival mode. Entry codes and similar arrival credentials stay masked until the check-in window, then unlock automatically.
- 5
Access narrows after checkout
Once the stay ends, the session resolves to a reduced allowlist instead of full operational access, and stored guest session data is subject to retention limits.
Not everything in a stay is confidential — a welcome message or a photo gallery is meant to be read. The point is that the line between guest content and operational detail is enforced on the server, not assumed in the interface.
The boundary
What guests see, and what stays restricted
- The property presentation: name, cover image and photo gallery
- General check-in and check-out timing for the stay
- House information the host wrote for guests, once a guest session is active
- Wi-Fi and arrival details during the eligible stay window
- AI Concierge answers grounded in the host's saved stay knowledge
- Verified nearby-place suggestions for the area
Infrastructure
Platform protections, described exactly as implemented
Database-level access rules
Row-level security and ownership checks live in the database. Host queries are constrained to the signed-in account, and guest-facing reads run through purpose-built functions with fixed, narrow outputs.
Server-only credentials
Google Places and AI provider keys, plus privileged database access, are read from server environment variables inside server handlers. The browser never receives them.
Request ceilings on costly endpoints
The AI Concierge and nearby-place lookups carry fixed-window request limits. This is an abuse ceiling in front of paid providers — a cost and load protection, not an authorization mechanism.
Scoped, expiring guest sessions
Guest session tokens are bound to one property and one eligible stay, re-checked server-side on every request, and pruned by scheduled retention jobs.
Conservative security headers
Every response carries HSTS, nosniff, a strict referrer policy, SAMEORIGIN framing and a restrictive permissions policy. A Content Security Policy is not yet enabled — we would rather say so than imply one.
Private media with signed links
Photos and welcome videos live in a private storage bucket. Guest pages receive short-lived signed URLs minted on the server rather than permanently public files.
TapStay is served over HTTPS and enforces it with HSTS. We hold no security certification or audit report today, so nothing on this page should be read as one.
Payments during the Early Pilot
TapStay does not collect payment card details in the current Early Pilot onboarding flow. Your first active property is free with no credit card required, and no live payment processor is connected to that flow today.
For hosts
What this means in practice
Share a stay link without worrying
If a link is forwarded or indexed, it still cannot hand over your Wi-Fi password, entry code, phone number or exact address.
Arrival details unlock on schedule
Codes appear when the check-in window opens, so you are not choosing between guest convenience and exposing credentials early.
Your data stays yours
Property, stay and reservation records are scoped to your account in the database, not merely hidden in the interface.
No card to hand over to try it
The Early Pilot onboarding never asks for payment card details, so evaluating TapStay carries no billing exposure.
FAQ
Security questions hosts actually ask
Questions about security? We're happy to explain.
The Privacy page covers what data is stored and for how long, and About TapStay explains what the product does and does not do. Hosts signed in to TapStay can reach us through the in-app help option.
