Privacy policy

1. Who controls your data

Stayed is operated by Hugo Hodinka, an individual established in Barcelona, Spain. You can reach us at hello@stayed.info. The site operator identification is on our impressum page.

The Agencia Española de Protección de Datos (AEPD) is this controller’s lead supervisory authority.

2. Scope

This policy covers the Stayed iOS app and the server infrastructure (the proxy) that supports it: hotel and destination lookups, email-forwarding and Google Calendar-based booking detection, push notifications, and the AI-generated area guide and concierge chat. It does not cover the marketing website, which is a separate surface with its own cookie statement.

3. What Stayed collects, and why

Stayed is built so that most of your data never leaves your device: stays, properties, loyalty memberships and certificates live in your own private iCloud database if sync is on, or locally if it is off (see section 9). What follows is what does leave the device, who receives it, and why.

4. Third parties that receive data

This table lists everyone who receives data when you use Stayed. Most rows are processors acting on Stayed’s instructions; one receives no personal data at all; and one is reached with no contract in place.

Anthropic, Vercel, Upstash and Resend are processors acting on Stayed’s instructions, and each needs a data processing agreement with the controller. Apple’s role for WeatherKit, MapKit, CLGeocoder and APNs, and Google’s role for Places autocomplete and the Calendar connection, can differ by service, and for some of what they receive either may be an independent controller rather than a processor. Wikimedia is not a processor: it is reached directly from your device with no contract of any kind. Frankfurter is not a recipient of personal data at all.

5. What is called directly from your device, not through the proxy

For most of what Stayed does, your device talks only to Stayed’s own proxy, and the proxy talks to the third party on your behalf, so the third party does not see your device or its IP address directly. That is true of the confirmation text and free-text questions sent to Anthropic, of Google Places autocomplete, and of the LiteAPI search, match and detail lookups.

Three things work differently, and in each of these three the third party (or a content-delivery network in front of it) receives your device’s real IP address directly:

• Wikimedia.The city-image lookup, and the area-summary’s Wikivoyage and Wikipedia references, are called directly from the device.
• Google, for the Calendar connection. Connecting Google Calendar exchanges an authorisation code for tokens directly between your device and Google, and the one-time historical backfill that follows, which scans up to five years of calendar history, also queries Google directly from the device. Once the connection exists, the ongoing once-a-day check for new events runs on the server (see section 6).
• LiteAPI, for the photo file itself.The proxy’s hotel lookup returns a photo URL, but the image bytes behind that URL are downloaded directly from your device every time a stay card renders that photo. The JSON lookups that produce the URL go via the proxy as normal; only the image download is direct.

6. Google Calendar

If you connect Google Calendar, Stayed reads calendar events under the OAuth scope calendar.events.readonly. The connection itself, and the one-time backfill scan that follows it, run directly between your device and Google, not through Stayed’s proxy (see section 5).

• The refresh token that keeps this connection alive is encrypted (AES-GCM) and stored on Stayed’s server (via Upstash), not on your device. Your device keeps no copy of it.
• A server-side process checks your calendar on a schedule, once a day, whether or not your phone is on, unlocked, or in range of a network. This is not continuous monitoring and it is not real-time; it is a once-daily check.
• Even though the calendar event’s own text is not stored beyond what is needed to extract a booking, the draft extracted from it, including the guest name, is kept for 30 days while you decide whether to confirm or dismiss it (see section 7).

7. How long we keep things

These periods are enforced by the infrastructure itself, not only stated in this policy:

• Pending drafts awaiting your confirmation: deleted automatically after 30 days.
• Account records: expire after approximately 400 days of inactivity; every delivery or authenticated read of your account resets the clock, so an account in active use never expires and an abandoned install does not linger indefinitely.
• Rate-limiting keys: expire after 24 hours.

8. Data about people who are not Stayed users

Stayed necessarily holds information about people who are not its users and who have not consented to anything: the guest name on a confirmation, which may name a travelling companion or colleague rather than you; the sender address and sender domain of every forwarded email kept during the 30-day pending window; the full text of forwarded emails sent to Anthropic for parsing, which can include other guests, hotel staff and booking-site correspondence; and messages sent to hello@stayed.info or through in-app feedback, which are relayed onward for handling.

We have no practical way of giving these people direct notice: we generally have no way of identifying or contacting them beyond what happens to be written in someone else’s forwarded email. Article 14(5)(b) of the GDPR permits relying on this where direct notice would involve disproportionate effort, provided the controller instead makes the required information publicly available. This section, together with the table in section 4, is that public disclosure.

9. Apple iCloud and CloudKit

If iCloud sync is on, your stays, properties, loyalty memberships, loyalty certificates and profile sync to your own private CloudKit database, including door PINs, guest names, room numbers, and the original confirmation document you shared into the app (stored as rawDocument, up to 5MB).

Data in a user’s private CloudKit database, which Stayed itself cannot read, is not counted as collection for the App Store’s privacy nutrition label, and it is correctly left off that label on that basis. Whatever Apple’s correct characterisation turns out to be, Apple is still processing this data on Stayed’s behalf in a data-protection sense, and is named in section 4 for that reason. Data is protected at rest with file protection set to become accessible after your first unlock following a restart of the device.

10. Location

Your home city, used to personalise the app, is detected from a single, one-off location fix taken on your device. That fix is reverse-geocoded on the device itself; only the resulting city name is stored, and neither the fix nor your precise location is ever transmitted anywhere.

Property location works differently. A property’s geographic coordinates, not your own location, are sent to Anthropic to generate the area guide, and to LiteAPI to look up the property. This is precise geolocation tied to a specific stay, even though what it describes is a hotel rather than a device.

11. No tracking, analytics or advertising

Stayed contains no analytics, no crash reporting, and no advertising or tracking software, and it never has. This is a genuine, verifiable design choice, not an oversight: it does not use your device’s advertising identifier, and the app’s own “Data Used to Track You: No” declaration is accurate.

12. Device identity, without an account

Where Stayed needs to recognise your device without creating an account for you, it uses a value calculated by hashing a stable per-device identifier together with the current UTC date. That value rotates every day, cannot be reversed to recover the original identifier, is hashed again on the server before being used as a lookup key, expires after 24 hours, and is reset completely if you erase all data. It cannot be used to link your activity across different days.

13. Automated processing and human review

When an email is forwarded to Stayed, an AI model classifies it and extracts booking details. Results the model is not confident about (below a 0.3 confidence threshold) are discarded automatically and never become a draft. Anything that does become a draft is reviewed by you: nothing joins your record until you confirm it.

We do not consider this a decision based solely on automated processing producing a legal or similarly significant effect on you, within the meaning of Article 22: no booking, charge or entitlement is created without your explicit review and confirmation. This section describes the logic regardless, as Article 13(2)(f) requires whenever automated processing takes place.

14. Forwarded email is read in full

If you set up email forwarding, mail sent to your forwarding address is fetched and read in full, not scanned only for booking-shaped content. An allow-list of senders, which you build up over time, limits what is accepted going forward, but it does not retroactively filter anything already received, and until you add your first sender it accepts mail from any address. We ask you, in the app itself, to forward selectively rather than forward everything; this section states the technical reality regardless of how selectively any individual user actually forwards.

15. Google API Services User Data Policy

Because Stayed requests the calendar.events.readonly scope, Google’s API Services User Data Policy applies to how calendar data is used, in addition to Google’s general terms. In line with the Limited Use requirements of that policy:

• Calendar data is used only to detect and help prefill hotel bookings for you. It is not used for advertising and it is not sold.
• Calendar data is not used to train general-purpose machine learning or AI models, whether Stayed’s own or a third party’s.
• Calendar-derived text is nonetheless sent to Anthropic, in the same way as any other confirmation text, in order to extract stay details.

16. International transfers

Several parties named in section 4 (Anthropic, Vercel, Resend, Google, Wikimedia) are based in the United States. For the processors among them, each transfer outside the EEA requires a currently valid transfer mechanism under Article 46, typically the EU Standard Contractual Clauses. Wikimedia’s position is different again: because it is reached directly from the device with no contract at all, the standard processor-to-processor clauses do not fit it, and it is disclosed here precisely so that this direct, contract-free call is not hidden.

17. Security

We describe our security measures as they actually are.

• Google Calendar refresh tokens are encrypted (AES-GCM) before being stored server-side.
• Push notification (APNs) device tokens are currently stored in plain text within the same server-side account record. This is an inconsistency, recorded here rather than smoothed over: the calendar token is sealed and the push token is not.
• The email-sync account token, the credential that keeps your Stayed forwarding address working, is stored in the device keychain. It becomes readable after your first unlock following a restart, and is included in your encrypted device backups, so restoring a backup onto a new device carries the same token over and keeps the same forwarding address rather than issuing a new one. A separate, pending-deletion queue is held to a stricter standard: available on this device only, excluded from backups entirely, so a deletion already under way does not resurrect itself on a restored device.

18. Your rights

You have the usual rights under the GDPR: access, rectification, erasure, restriction, portability, and objection, plus the right to withdraw consent at any time where processing is based on consent, and the right to complain to a supervisory authority (see section 20).

Erasure in Stayed is more thorough than most apps: deletions happen record by record so that CloudKit tombstones propagate correctly rather than leaving orphaned data behind; a Keychain-backed retry queue survives the app being closed or killed, so server-side deletion still completes even if you erase your data while offline; and disconnecting your account also revokes the Google token and deletes your account record, stored tokens, and any pending drafts held server-side.

Access and portabilityare weaker today. Stayed’s built-in export is being extended, but even once extended it will not cover data held on Stayed’s servers rather than on your device. Until a server-side export exists, if you want a full copy of your data, or wish to exercise your right of access or portability, email hello@stayed.info and it will be compiled for you.

19. Legal bases

Processing needed to provide the service you have asked for (parsing confirmations, syncing your data, showing an area guide) relies on performance of the contract between you and Stayed. Security and fraud-prevention measures rely on legitimate interests. Where a feature is optional and separately switched on, such as email forwarding or Google Calendar, connecting it is itself the basis for that specific processing; disconnecting it stops the processing going forward, subject to the retention periods in section 7.

20. Complaints

You may lodge a complaint with the Agencia Española de Protección de Datos (AEPD), this controller’s lead supervisory authority, or with the supervisory authority in your own EU member state.

21. Changes to this policy

We may update this policy as Stayed changes or as the law requires. When we do, we will change the date at the top of this page. Where a change materially affects how we handle your data, we will also surface it in the app rather than relying on you to re-read this page. Using Stayed after an update means the current version applies to you.

22. Contact

hello@stayed.info