Where the system runs
MyRentalCalendar runs on infrastructure we operate ourselves. The application, the database and the file storage sit on servers under our own administration. Every connection is encrypted in transit with TLS 1.2 or 1.3, modern cipher suites and forward secrecy, and HTTP Strict Transport Security with a one-year lifetime covers every subdomain.
Each application has its own host: the console at admin., the landlord portal at owners., the cleaning portal at cleaning., the developer portal at dev. and the API at api.myrentalcalendar.com. The API host answers only on the paths built for partners, AI agents and public booking websites.
Signing in
Passwords are stored as Argon2id hashes. Sign-in with Google, Apple or Microsoft is supported, so an agency can rely on the second factor its identity provider enforces.
A session consists of a short-lived access token, valid for 15 minutes and held in an httpOnly cookie that scripts cannot read, plus a server-side refresh session of seven days that can be revoked at any moment. Signing out deletes the session on the server, which ends the refresh chain immediately.
Three wrong passwords lock an account for five minutes for the address that got them wrong. The same account keeps working from everywhere else, so nobody can lock an agency out of its own console by hammering a known e-mail address. Addresses that keep failing across accounts are blocked before the request reaches the database. Sign-in, sign-up and every public endpoint are rate-limited.
Who sees what
Every page, button and endpoint is gated by a named permission. Roles are bundles of those permissions, managed by the agency in its own rights console, and a permission that does not exist in the code cannot be granted. Teams organise people and grant nothing.
Landlords and cleaning partners sign in to separate portals with separate audiences. A landlord session reaches only the landlord endpoints and only the data of that landlord's units. A cleaning session reaches only the cleaning endpoints and the jobs assigned to that crew. The guards deny by default.
Separation between agencies
Every record carries the agency it belongs to, and every query the server runs is scoped to that agency. No business endpoint reads data across agencies. Each plan carries a hard limit on the number of units an agency can create, and sign-up is rate-limited, so one tenant cannot exhaust the platform for the others.
Encryption of sensitive data
Passport and ID details of travelling guests are encrypted with AES-256-GCM under a key generated for that one booking. The key is deleted 365 days after departure; the encrypted rows remain as a count and become permanently unreadable. Removing the guests from a booking deletes rows and key immediately. The system enforces the forgetting.
Credentials the platform must reuse on your behalf, such as an SMTP password, an Anthropic key or archive storage credentials, are stored as AES-256-GCM ciphertext under a server key kept outside the database. Partner API keys are shown once and stored only as a SHA-256 hash. Audit records replace passwords, tokens, card numbers, IBANs and door codes with a redaction marker before they are written.
The audit trail
Every write request and every business event, from a booking change to an issued invoice to a sign-in, is appended to a journal in the same database transaction as the change itself. Each record is chained to its predecessor with SHA-256, every day is sealed with an Ed25519 signature, and the console can re-verify any range and report the first record that no longer matches. The journal follows the GoBD standard for immutable bookkeeping records, and it is how we would reconstruct an incident.
Your data
You can download a complete copy of your master data as SQL or CSV in a ZIP at any time from the Archiving page, without asking us. You can also connect S3-compatible storage of your own, such as AWS S3, Cloudflare R2, Backblaze B2 or MinIO, and schedule automatic archives into it. When you leave, we hand your data over and delete our copy.
Guest ID details follow the 365-day rule above. Booking and invoicing records stay for as long as your tax and tourism obligations require them.
Guests and website visitors
This marketing site sets no cookies and makes no third-party requests. Your booking website serves its fonts from our servers, loads map tiles only after the visitor consents, and runs under a Content Security Policy that blocks scripts and connections to anything else. Bot protection on the enquiry form uses Cloudflare Turnstile once you switch it on.
The AI concierge on your website answers within the tools it has: searching availability, unit details, exact quotes, areas, creating an enquiry and handing over to WhatsApp. It has no tool that reads guest records, bookings or finances. Conversations are processed by Anthropic, and you can run the concierge under your own Anthropic key.
Partner API and AI agents
API keys are generated in your own portal, bound to one audience (agency, landlord or cleaning partner) and, where applicable, to one landlord or one crew. Each key carries explicit scopes, has its own rate budget and can be revoked on its own. Requests authenticate with a bearer key, so there is no cookie and no CSRF surface. Passport and ID details never leave the system through any API or export.
Operations
Every response carries the hardening headers a browser expects: a Content Security Policy, X-Frame-Options DENY, nosniff, a strict Referrer Policy and a Permissions Policy that switches off camera, microphone, geolocation and payment APIs. The API host answers with default-src 'none'.
Releases pass through a gate. The new version must answer its health check before traffic is switched to it, and if it does not, the deployment rolls itself back to the previous version.
