Your guests' data,
and your money.
Two things a hotel cannot afford to lose. This page explains how the platform separates organisations, protects credentials and keeps money accountable — and where the limits of a pilot-stage company are.
Organisations are separated by the address
Every request resolves its organisation from the hostname and every tenant route re-checks the caller's membership. A valid session for one hotel cannot read another's guests, folios or reports; the API refuses the mismatch before any row is read.
LivePasswords are hashed, sessions rotate
Passwords are bcrypt-hashed. Access tokens live fifteen minutes; refresh tokens rotate on use and are revoked when a password is set. Invitations and resets are single-use, purpose-scoped, hashed at rest and time-boxed.
LiveMoney cannot be quietly edited
Folio totals are computed from charge, payment and refund rows. A payment carries an idempotency key so a retry cannot post twice. Gateway deliveries are signature-checked and stored before they are applied.
LiveMerchant keys are sealed
Each operator connects its own gateway account. The secret key is encrypted with AES-256-GCM and returned only as a hint. Card numbers are entered at the provider, never at NiroStay.
LiveEvery sensitive action is attributed
Posting money, changing a status, inviting a teammate, proving a hostname: each writes an audit entry with the actor, the resource and a correlation id.
LiveGuest data has a narrow purpose
A guest's name, contact and stay are used to run the stay and send the messages that stay requires. Marketing consent is a separate, explicit field and is never assumed from a booking.
LiveBranding cannot inject code
Colours must be hex, logos must be an HTTPS address or a local path, and every operator-supplied string in a page or an email is escaped. A property name is a name, not markup.
LiveAbuse has a budget
Credential endpoints are rate limited per address, public booking routes have their own limit and hold sweeper, and webhooks are signature-checked. The limits are in-process today.
PilotData leaves with you
Reservations, guests, folios and reports export as CSV. Ending an agreement does not require a support ticket to retrieve your own operational history.
LiveFewer moving parts is a security decision.
The console, the guest pages and the API are one deployment against one PostgreSQL database. There is no second copy of a guest list to fall out of sync.
- Server-side authorisation. The browser never decides what money means or which property a person may see; it renders an answer the API computed after checking membership.
- One tenant per request. The address and the payload must agree about whose data this is. A cross-organisation id returns 403 or 404, never data.
- Uploaded files are validated. Logos are checked by content type, size and image dimensions, stored as bytes with a checksum, served with an ETag, and refused while in use by a page.
- Production refuses weak defaults. The API will not boot with the development JWT secrets, a missing email provider key, or no payment-encryption key when a gateway is connected.
- Links are never passwords. Invitations and resets are emailed, single-use and expire. Setting a password revokes every other session on the account.
- Delivery is visible. Every sent message is recorded with the provider's verdict, so a bounced invitation is a fact in the console rather than a silence.
What we do not claim.
Security pages usually list certifications. This one also lists the gaps, because you are trusting a young company with a guest list.
No SOC 2 or ISO 27001
We have not completed a formal certification programme. Our controls are documented in the platform's security notes and can be walked through on a call.
No third-party penetration test
One is planned before general availability. We will publish the summary when it happens, including anything it finds.
Single-instance components
Rate limiting and the hold sweeper are in-process today, so they are per-instance. Multi-instance hosting needs shared state; that is a known gap, not a surprise.
Backups are agreed per deployment
Database backup and retention are set at the infrastructure layer for each deployment and confirmed during onboarding. We do not advertise a number we have not verified.
Self-serve plans carry no SLA
A service-level agreement is part of the Enterprise conversation. On self-serve plans we aim to be available and say so plainly when we are not.
Channel connections are new
The Channex adapter is tested against a stub provider. Live OTA connections are onboarded one property at a time, with the mapping checked before inventory moves.
Tell us before you tell anyone else.
If you believe you have found a vulnerability, write to [email protected] with enough detail to reproduce it. We will acknowledge within two working days and keep you informed until it is fixed.
Ask us the security questions.
Bring your IT reviewer. We will walk through tenancy, credential handling, payment flow and the gaps on this page without a slide deck.