Security, data & platform: questions and answers

bedsKey is multi-tenant, and each hotel group's data is isolated at the database level with row-level security, so one tenant's queries cannot read another tenant's rows.

Yes. Role-based access control uses granular per-action permissions and custom roles, and a user can hold different roles at different properties.

Yes. Rate overrides, discounts, voids, refunds and folio adjustments can be set to require an authorised user.

Yes. Every change is recorded with who, what, where and when, including field-level before and after values. The trail is append-only, so entries cannot be edited or removed.

Passwords are hashed with Argon2id. Sessions use JWTs that can be revoked, and sign-in is rate-limited. On shared handsets, sessions live only in the device keystore.

Passport and national ID scans are encrypted with AES-256-GCM, viewing them needs a separate permission, every view is audited, and documents are deleted automatically after your retention period.

No. Card payments are taken on the payment gateway's own page, so card numbers never reach bedsKey.

Yes. bedsKey runs on managed PostgreSQL with automated backups.

Real-time sync over WebSocket pushes every reservation, room-status and folio change to every open screen the moment it happens, so reception, housekeeping and managers see the same picture.

System Health monitoring covers service status, background jobs, queues, card-hold countdowns and outbound delivery. Database Health monitoring covers the connection pool, slow queries, index and table health, with guided integrity checks.

A Go backend; PostgreSQL 18 with exclusion constraints and row-level security; exact decimal arithmetic for money; Redis for token revocation, permission cache and rate limiting; a React and TypeScript web app; Flutter for the iOS and Android apps; WebSocket for real-time updates; and a Caddy edge with automatic TLS.