What an independent host needs to know before plugging Nightwell into their channels: the data we touch, where it lives, who can read it, how long it stays, and how a host takes it all back when the relationship ends.
What we touch
Three categories of data, in plain language. Nothing else — no surveillance surface, no marketing trackers, no third-party enrichment behind the host’s back.
The descriptions, photo metadata, pricing rules, house-rules text and check-in instructions a host already publishes on their own channels. Calendars sync from the channel the host connects — Nightwell reads them, never writes back to the channel of record unless the host has configured that connection.
Subject lines, message bodies, timestamps and the channel each message arrived on (email, the platform’s own inbox, or a connected channel). Attachments are stored when needed for verification — ID photos for security deposits, proof-of-damage claims, and the like.
Cleaner assignments, the schedule window for a turnover, the job card briefing each cleaner works from, and the time-stamped photo proof-of-completion the cleaner sends back. This data lives alongside the listing it’s servicing, not as a separate dossier.
Storage and access
The host’s account is a tenant. Nightwell staff do not see inside it without the host opening the door, and the door stays closed by default.
Every host account sits inside a per-host tenant boundary keyed on the host’s account ID. The agent, the message archive, the cleaner roster, the action log and the listing records all live inside that boundary. No Nightwell workflow reads across tenants — a search on one host’s data never returns rows from a neighbour.
Nightwell staff only have read-access to a host’s tenant when the host opens a support ticket and explicitly grants it for the duration of that ticket. Every staff read is logged inside the host’s action log with a timestamp, the staff member and the reason given. The host can see the log on demand and revoke access at any point during the ticket.
A small number of named sub-processors sit behind the platform: the authentication provider that issues the host’s session, the managed database the data records live in, and the transactional email service that delivers the morning brief and the turnover job cards. Sub-processor changes are announced in the changelog the week they ship, not the quarter after.
Retention
Data ages out on the host’s behalf. Nothing useful stays forever; nothing a host asks to remove lingers behind the scenes.
Guest messages and the reservation-context records tied to them (channel timestamps, verification attachments, escalation notes) are held for the active reservation window and then for a defined grace period after the stay ends. Once the window closes, the records age out on a stated schedule — the host does not need to ask.
Cleaner coordination — the assignments, the schedule windows, the job cards and the proof-of-completion photos — follows the listing’s operational retention, which tracks the listing’s active-booking history rather than a fixed calendar. When a listing is paused or removed, the coordination records age out with the same grace period the guest messages get.
Backups are run on a regular cadence against the production database and are retained on a rolling window long enough to recover from an outage, then aged out in turn. Backups live in the same provider region as the production database and are encrypted at rest.
A host-initiated deletion request is honored within 30 days of confirmation — not because it takes that long technically, but so the host has a window to reverse the decision if they sent the request by accident. Purges are confirmed in writing and visible in the action log on the same surface that originated the request.
Host control
The host’s data is the host’s data. Exports and account deletion run from inside the platform — never behind an outside form the host has to chase.
A per-host export request delivers a portable archive of the host’s own listings, message threads, cleaner roster and pricing policy, packaged in a format a rival platform — or a spreadsheet — can read. Exports are initiated from the host dashboard inside the platform, run on demand, and the file is delivered to a download link the host alone can open.
Account deletion runs from the same surface. Confirming the deletion revokes the per-property access tokens Nightwell has issued to the host’s cleaners, removes the host from the active-channel roster, and starts the retention-clock countdown described above. The host does not need to email a human to make it stick.
Everything written above is what is shipped in production. The export endpoint is the endpoint that builds the file the host downloads; the deletion endpoint is the endpoint that scrubs the row; the retention schedule is the schedule the database actually runs. If a claim on this page ever stops being true, the page gets edited the same week — same posture as the rest of the public site.
Talk to a human if you want more
Procurement, legal, an internal security review — drop a note through the contact form with as much context as you can share, and the operator will write back with a longer sit-down answer rather than the marketing line. We answer within one business day.