Privacy and data handling

Local prototype for synthetic data only. This application has not been deployed for real host or guest data. No controller identity, operator contact, production region, processor/DPA approval, or transfer mechanism is published here. Do not use real personal data until those external gates are complete.

The local app database stores host account references, property details, guide sections and translations, the alert address, share-link hashes, the inbox, setup events, audit rows, rate-limit fingerprints, and counters. Host sign-in data is held by the local Supabase Auth service.

Guest link and QR code

The link and QR code are bearer credentials. Anyone who has the link can open the published guide. Do not post it publicly. The host can rotate or disable the link; that deletes the old link secret and its guest sessions. Deleting the property removes the guide and property data.

Guest data

• Guests do not create an account. The app sets a random, HttpOnly guest session cookie scoped to /g for up to 12 hours; the server stores only a hash of the session token.
• Choosing a guide language sets an HttpOnly sw_lang cookie scoped to /g for 180 days. It holds only the language code, applies to every guide opened on that device, and falls back to the guide's original language when the host has not enabled it.
• When the host adds a phone number and usual answering hours, guests see them on the guide's Home and Help pages after opening their link, with a Call link. They are never shown on the opening, unavailable, or error pages and are never sent for translation.
• When the host adds an address, the guide shows it with an "Open in maps" link to OpenStreetMap. Nothing is loaded from the maps provider until the guest clicks; only then does it receive the address.
• A guest message stores the message text, question/issue choice, topic, locale, optional reply email, submitted time, new/handled state, and the host's optional "answer was in the guide" tag. The reply email is guest-supplied and unverified.
• Per-property daily counters store only link exchanges, guide opens, and submissions. They contain no guest identity or content. The app does not use third-party analytics.

Retention and deletion

• Guest messages and optional reply email are deleted 90 days after receipt, or earlier when the host deletes the message. Guests can ask the host to delete a message; there is no guest self-service deletion.
• Deleting a property immediately removes its guide sections, translations and provider metadata, share links, guest sessions, messages, rate-limit fingerprints, counters, reservations, setup events, and property-scoped API-token rows. A minimal delete audit row remains for the 90-day audit window.
• Audit and setup events are deleted after 90 days. Disabled-link metadata is deleted after 30 days; expired guest sessions and old rate-limit windows are removed by cleanup. Guest counters are deleted 400 days after the day they count. Reservations are empty in this pilot; the schema deletes them 90 days after the stay end date.
• A host can delete their account from Settings. Deletion is immediate and cannot be undone: it removes the sign-in account, every property and everything stored for it, host defaults, and setup events. Earlier audit rows lose their link to the host, and one account_deleted row without identity remains for the 90-day audit window. Records outside the app database are not erased by this step: the Supabase Auth service's own audit log (which can contain the email address), mail-delivery logs, and provider backups follow the provider's retention. No published operator contact is implemented yet.

Host alerts, logs, and translation

• A new-message alert contains fixed text and the host's stored alert address; it does not include the guest message, category, property name, or reply email. Real SMTP delivery and provider retention are not exercised here.
• Application logs use an allowlisted, flat set of operational fields. They do not contain guest message text, reply addresses, guest session tokens, or link fragments. Hosting and database provider logs are outside this local review.
• Only a host's explicit "Generate translations" action can send eligible guide prose to the configured translation provider. Guest messages, host notes, secrets, and contact details are not part of that payload; the local configuration has translation egress off and makes no Google call. Provider terms, DPA, and EU endpoint review remain external.

Before real data

This notice describes implemented local behavior; it is not a completed legal policy. Before any real host or guest personal data, the operator must name the controller and contact, publish final production retention/deletion terms, complete processor/DPA and transfer reviews for hosting, database/auth, SMTP, and translation, choose verified regions, and validate backup/PITR retention. Emergency and access copy must be reviewed separately.

Back to Staywise · Host sign in