Privacy policy

1. Who controls your data

The Stayed app 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, currency conversion, the AI-written area briefing and concierge, the optional check-in suggestion and optional photo matching. It does not cover the marketing website, which is a separate surface with its own cookie statement.

3. What the Stayed app collects, and why

The Stayed app 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 when your device is signed in to iCloud, and only on the device when it is not. There is no separate sync switch in the app (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 the Stayed app. Most rows are processors acting on the Stayed app’s instructions; one receives no personal data at all; and one is reached with no contract in place.

Anthropic, Vercel, Upstash, Resend and Mixpanel are processors acting on the Stayed app’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 the Stayed app does, your device talks only to the Stayed app’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, the Stayed app 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 the Stayed app’s proxy (see section 5).

• The refresh token that keeps this connection alive is encrypted (AES-GCM) and stored on the Stayed app’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 the Stayed app users

The Stayed app 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 your device is signed in to iCloud, 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 the Stayed app 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 the Stayed app’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 and photos

Your own location: approximate only, and only if you ask for it.The Stayed app uses your device’s location for two things, both off until you turn them on. The first is working out your home city, once, so it can tell a trip from a night at home; you can type the city in instead. The second, added in version 1.7.0 (September 2026), is a suggested check-in time, described below. The app never asks for your location on its own.

When you do use the button, the Stayed app asks iOS only for your approximate location, never your precise one. This is not a promise about our restraint: the app is configured so that iOS will not give it a precise fix even if you wanted to grant one, so the precise location of your device is not something the Stayed app is capable of collecting. A city name does not need metres.

That approximate coordinate is sent to Apple’s mapping service to be turned into a city name. It is not sent to the Stayed app’s own servers, and it is not sent to anyone else. Only the resulting city name, and that city’s own coordinate, are kept. An earlier version of this page said the fix was reverse-geocoded on the device itself and never transmitted anywhere. That was wrong: reverse geocoding on iOS is a network call to Apple. The correction is stated here rather than made quietly, because a privacy policy that overstates how little leaves your device is a worse failure than one that understates it.

Suggested check-in time.If you turn this on in Settings, then each time you open the app on a day you have a stay booked it takes one approximate fix, snaps it on the device to a grid about 5 km across, and compares it in memory with the area of the hotel you have booked. If they match, the app offers a suggested time beside the check-in button (“Your phone was in the area at 15:38”). It never records a check-in for you: “checked in” and “checked out” are always your own taps. It never runs in the background, never turns the fix into an address or place name, never sends the coordinate to our servers or to anyone else, and is suppressed in your home city. The times it keeps are stored with the stay, on your device and in your own iCloud. “Forget all sightings” in Settings deletes every one of them, and turning the feature off offers to do the same rather than doing it silently.

Your photo library (Stayed Pro).If you use photo matching, the app reads your photo library on the device to find pictures taken between the check-in and check-out of a past stay, within about 20 km of the hotel. It runs only when you ask, one stay at a time, never in the background, and screenshots are excluded. Nothing is uploaded: no photo, no thumbnail and no photo location leaves your device. Choosing a photo as the stay’s cover, or hiding one from a stay, is recorded with the stay on your device and in your own iCloud.

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. Those coordinates are precise, and they are tied to a specific stay of a specific user, even though what they describe is a hotel rather than a device.

11. Advertising, tracking, and optional analytics

What has not changed.The Stayed app contains no advertising, no ad tracking, and no crash reporting. It does not use your device’s advertising identifier and it never sells your data. No advertising or analytics company’s software runs inside the app: the only third-party code in it is RevenueCat, which handles Pro purchases and is described in the table above. The App Store label’s “Data Used to Track You: No” declaration remains accurate.

What is new.The Stayed app offers optional product analytics, switched off by default. The app is fully functional without them, and nothing at all is measured unless you turn them on. The switch is called “Help improve the app”, in Settings, and the same switch turns it off again.

What is sent when the switch is on.Events describing which features get used and what goes wrong: an event name from a fixed list (for example that a stay was saved, or that a parse failed), properties drawn from fixed vocabularies (category tokens, yes/no values, and small bucketed counts), a random analytics identifier created at the moment you consent, the app’s version, your device’s major OS version, and whether you currently have Stayed Pro.

What is never sent.No hotel, property or chain names; no cities, countries or coordinates; no dates of stays; no confirmation numbers, access PINs or room numbers; no guest names or counts; no loyalty member numbers; no email addresses; no calendar event titles; no notes, questions, pasted text or anything else you typed; no monetary amounts, prices, plan names or transaction records; no device model, screen or carrier details; and not your IP address, because events travel through the Stayed app’s own server, which does not pass it on. The event vocabulary is enforced on that server: an event or property outside the fixed schema is dropped, so booking content cannot reach the analytics system even by a programming mistake. No analytics event is emitted from inside the on-device calendar scan or the email processing pipeline; what is measured is the actions you take in the app.

What this is not for. These analytics are about how the app is used, not about what you have paid for. Nothing about a purchase is sent: not what you bought, not when, not for how much, not which plan, not whether a trial started or a subscription renewed or lapsed. The only thing related to Pro that travels is whether you have it right now, so that a chart can tell free use apart from paid use. Subscriptions are measured separately, by RevenueCat, which is named in the table above and receives only what you bought and when. That is a different system from the one described here, and the two are never joined.

Who processes it.Mixpanel processes these events for The Stayed app as a processor, on the Stayed app’s instructions, and for no purpose of its own. There is no Mixpanel code in the app; the app talks only to the Stayed app’s server, and the server forwards conforming events to Mixpanel.

The identifier. The analytics identifier is a random value, created only when you consent. It is not derived from, and cannot be joined to, the rotating device identifier described in section 12. It is deleted when you turn the switch off and when you erase all data; if you later turn analytics on again, a fresh identifier is created, and events sent under the old one cannot be connected to events sent under the new one.

Nothing at all is collected before you say yes. Before you turn the switch on, the Stayed app records nothing, writes nothing and queues nothing, not even locally on your own device. There is no buffer sitting in the app waiting for a yes, no file of events held back, and no identifier in existence. If you never turn the switch on, there is nothing to send, nothing to delete, and nothing that was ever written down. If you turn it on later, measurement begins at that moment and covers nothing that happened before it. That leaves a real and permanent gap in what we can learn about our own product, accepted deliberately, because the alternative is collecting something from people who have not agreed to it.

Legal basis.Consent (Article 6(1)(a) GDPR), and, for storing and reading the identifier on your device, the consent rule in Article 22.2 of Spain’s LSSICE. Analytics are not necessary for the service you asked for, so no other basis is claimed for them.

Withdrawing. Turn the switch off. Sending stops immediately, and the identifier and any events still queued on the device are deleted. Withdrawal does not affect the lawfulness of processing that happened while consent was in force. If you also want the events already held by Mixpanel deleted, email hello@stayed.info: the deletion is run against Mixpanel’s deletion interface, which Mixpanel states can take several weeks to complete.

How long events are kept. Analytics events are kept no longer than they are useful, and what makes them useful is a full cycle of travel seasons: a shorter window can only ever compare unlike parts of the year, so it cannot answer whether the app is being used more, which is most of what this data is for. The exact retention period is being set at the processor, and it will be stated here once it is set and enforced there rather than only promised here. You do not have to wait for it: you can ask at any time for the events already held about you to be deleted, by the route just above.

Where it is processed.Analytics events are sent to Mixpanel’s EU ingestion endpoint rather than its US one. Mixpanel is a US company, so section 16 covers it alongside the other US recipients.

12. Device identity, without an account

Where the Stayed app 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.

This rotating identifier is deliberately separate from the optional analytics identifier described in section 11. The two are generated independently, neither is derived from the other, and they cannot be joined: the rotating identifier keeps its cannot-link-across-days property for lookups and parsing whether or not you ever turn analytics on.

13. Automated processing and human review

When an email is forwarded to the Stayed app, 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 the Stayed app 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. The Stayed app’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically:

• Calendar data is used only to detect and prefill hotel bookings for you. It is not used for advertising, it is not sold, and it is not transferred to anyone for their own purposes.
• Calendar data is not used to develop, improve or train any machine learning or AI model, whether the Stayed app’s own or a third party’s.
• Calendar events are read, never written. The Stayed app does not create, edit or delete an event.
• The event text is never sent to a language model. A calendar event that looks like a hotel booking becomes a draft stay by field mapping and pattern matching alone, on your device or on our server. That draft is held for up to 30 days and joins your record only when you confirm it.
• One narrow exception, stated rather than hedged: when a draft is opened for review, the Stayed app looks the property up to fill in typical check-in and check-out times, and that lookup sends the hotel name and the city to Anthropic. Nothing travels with them, not your dates, your confirmation number, your email address or any identifier, and the lookup runs identically for a stay you typed in by hand. Anthropic’s API terms state that content sent to its API is not used to train its models.

Mail you forward to your Stayed app address is a separate path, described in section 4. It reaches us over SMTP rather than through any Google API, and its contents are sent to Anthropic for extraction. No Google calendar data travels that path.

16. International transfers

Several parties named in section 4 (Anthropic, Vercel, Resend, Google, Mixpanel, 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. Analytics events are sent to Mixpanel’s EU ingestion endpoint rather than its US one, which is why section 11 describes them separately; Mixpanel is a US company nonetheless, and to the extent any analytics data is processed outside the EEA, the same Article 46 requirement applies to it as to every other processor above. 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 app 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 the Stayed app 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. The Stayed app’s built-in export is being extended, but even once extended it will not cover data held on the Stayed app’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 the Stayed app. 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.

Product analytics rely on consent alone, as section 11 sets out, and on nothing else: they are not carried by contract or by legitimate interests, and they never operate without an affirmative opt-in.

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 the Stayed app 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 give notice of it before it takes effect rather than relying on you to re-read this page, and where the processing rests on your consent we will ask you again rather than treat an earlier yes as covering something new. Using the Stayed app after an update means the current version applies to you.

22. Contact

hello@stayed.info