How Your Data Is Protected

Running GuestsKey means handing over two sensitive things: access to your booking system, and the ability to open your doors. Here’s how both are held.

What’s encrypted at rest

Door codes, guest phone numbers, and the credentials for your connected integrations are encrypted before they’re written to the database, using AES-256-GCM with a per-value random initialization vector and an authentication tag that detects tampering. The key is derived with scrypt rather than used directly.

In practice that means a database backup, a stolen disk, or a query run by someone who shouldn’t be running it doesn’t yield readable PINs, guest phone numbers, or the tokens that reach your PMS and locks.

Codes are decrypted only at the moment they’re needed — sent to a lock, or shown to a guest on their portal page.

Your data is separated by account

GuestsKey is multi-tenant: many property managers share the same infrastructure, and separation is enforced in the application rather than by giving each customer their own database.

Every request carries which account you’re acting on, and the server independently confirms your user is a member of that account before anything runs — it doesn’t take the claim at face value from the browser. Queries are scoped to your account rather than filtered afterwards.

That rule is also enforced mechanically: an automated check runs on every code change and fails the build if a query that should be account-scoped isn’t. It’s a class of mistake that’s easy to make once and catastrophic to miss, so it isn’t left to code review alone.

Where it runs

Infrastructure is US-based.

What we’d tell you

If we ever found that your data had been exposed, you’d hear it from us directly — not from a status page footnote. See reporting a security issue for how to reach us if you spot something first.