Privacy Policy

This policy explains how Anyname Hotel handles personal data. The entity responsible is identified in the Contact clause at the end of this document.

It covers all of the following, which we refer to together as the "Service":

•The web application at app.anynamehotel.com.

•The Anyname Hotel application for iOS.

•The Anyname Hotel application for Android.

•The public website at anynamehotel.com, including its Turkish pages.

It is written to satisfy Law no. 6698 on the Protection of Personal Data ("KVKK") and, for hotels and guests to whom it applies, Regulation (EU) 2016/679 ("GDPR").

For guest and staff data entered into the Service, the hotel is the data controller and Anyname Hotel is the data processor acting on its instructions (KVKK: veri sorumlusu / veri işleyen; GDPR: controller / processor).

For the hotel's own account and billing records, for support messages sent to us, for enquiries submitted through the public website or from inside the app, and for the analytics described in clause 11, Anyname Hotel is the controller.

As a processor we act only on the hotel's instructions, given through the Service or in writing. We do not use guest data for our own purposes, do not sell or rent it, do not use it for advertising or profiling, and do not use it to train machine-learning models.

•Guest records: first and last name, email address, phone number, nationality, national identity or passport number, date of birth, the notes the desk adds, and any VIP or blacklist flag the hotel sets.

•Stay records: room, dates and times, number of adults and children, rate, folio charges, payments and the payment method.

•Company and agency records (Cari): company name, tax number, the name, phone and email of the contact person, and notes.

•Till and expense records: cash accounts, cash movements, expenses, suppliers and the staff member who recorded each one.

•Staff records: name, username, role, account status, and an append-only action log of what each account did — check-in, payment, correction, room status — with the account name, the time, and the network address the action came from.

•Property records: hotel name, legal name, address, contact details, currency, check-in and check-out times, and the hotel's own identity-reporting credentials where that integration is used.

•Device registrations for push notifications: the notification token issued by Apple or Google for a given handset, the platform, the app version and the chosen language, held against the staff account that signed in on that device.

•Where the hotel switches on the Telegram check-in bot: the Telegram chat identifier, user identifier and username of the people linked to it, and whatever a guest types into the bot while a check-in is in progress.

•Staff invitations, where used: the email address invited and whether the invitation was taken up.

We hold no special categories of personal data under KVKK art. 6 or GDPR art. 9. A national identity or passport number is an identity credential, not a special category, and the Service has no field for health, biometric, religious or political data.

•Enquiries sent from the public website or from the demo form inside the apps: name, hotel name, phone, city and the message written, so that we can answer and follow up.

•Support messages sent to us: sender name, the reply address given, the topic, the message, and which property it came from.

•Account-closure requests: who asked, when, any reason given, and our decision.

•Data-export requests: who asked, when, the reason given, our decision and any note, and whether the approved download was used.

•Licence and billing references for the property.

•Error and performance reports from the Service, as described in clause 10.

•Analytics and advertising measurement on the four public marketing pages, and only where the visitor has consented, as described in clause 11.

No card numbers, security codes or bank credentials are stored anywhere in the Service. Payments are recorded as an amount and a method — cash, card, transfer, mobile or on-account — and never as card data. If card payment is ever enabled, cards will be handled by a licensed payment provider and we will keep only its reference.

Processed for the hotel

•To run the property — assigning rooms, billing stays, reconciling the till and reporting to management. Basis: KVKK art. 5/2(c) and (f), GDPR art. 6(1)(b) and (f), on the hotel's instruction.

•To meet the hotel's legal duties, including guest identity reporting to the Turkish authorities and keeping accounting records for the statutory period. Basis: KVKK art. 5/2(a) and (ç), GDPR art. 6(1)(c).

•To keep the Service secure and to investigate misuse, using the action log. Basis: KVKK art. 5/2(f), GDPR art. 6(1)(f).

Processed by us as controller

•To answer enquiries and support messages and to keep a record of what was asked and what we did. Basis: KVKK art. 5/2(c) and (f), GDPR art. 6(1)(b) and (f).

•To keep the Service working — diagnosing crashes and errors. Basis: legitimate interest, KVKK art. 5/2(f), GDPR art. 6(1)(f).

•To bill and to keep our own statutory records. Basis: KVKK art. 5/2(a), GDPR art. 6(1)(c).

•For analytics and advertising measurement on the public pages. Basis: consent, KVKK art. 5/1, GDPR art. 6(1)(a) — withdrawable at any time.

Nothing in the Service makes an automated decision that produces a legal effect for a guest or a member of staff, or that similarly significantly affects them.

Flags such as VIP or blacklist are set by the hotel's own people, one record at a time. They are not calculated, not inferred from behaviour, and not shared between properties: a guest flagged at one hotel is unknown to every other hotel on the Service.

We use a small number of processors. Each is bound by a written data processing agreement, may act only on our instructions, and may not use the data for its own purposes.

•Supabase — database, authentication, file storage and push delivery. Hosting region as set for the project.

•Vercel — application hosting and content delivery for the web application and the public site.

•Sentry — error and performance reports, as described in clause 10.

•Apple (APNs) and Google (FCM) — delivery of push notifications to a registered handset. They receive the notification token and the message payload, which carries an event and a room number, never an identity document.

•An email delivery provider — only for support messages sent to us from inside the app, and only for the contents of that message. Guest records are never sent by email.

•Where the hotel enables them: the Turkish authorities, through the hotel's own identity-reporting account; and Telegram, only for the messages that flow through the optional check-in bot.

•On the public marketing pages only, and only after consent: Google (Analytics), Meta (Pixel and conversions), PostHog and Vercel Analytics. See clause 11.

Nothing is sold, rented, or used for advertising or profiling by us. Nobody outside these providers receives guest data unless the hotel instructs it, or a court or a law compels it — and where we are compelled and are lawfully able to tell the hotel, we do.

If we add or change a provider that handles hotel data, we tell the owner account before it starts, so the hotel can object or leave before it takes effect.

Our platform console can list properties, their licence state and their usage totals. A small number of our staff can also reach a property's records where it is genuinely necessary — to investigate a fault the hotel has reported, to restore data, or where the law requires it.

That access is limited to the people who need it, is used only for those reasons, and is not used to read guest records out of curiosity or for any commercial purpose. We do not sign in to a hotel's own account without asking the hotel first, except where we must to stop a live security incident.

Our staff are bound by written confidentiality obligations that survive the end of their engagement.

The iOS and Android applications are the same Service in a different shape. They talk to the same database, hold the same records, and are governed by every other clause of this policy. Four things are specific to them.

Device permissions

The apps ask for one permission: notifications. They do not use the camera, the photo library, the microphone, location of any precision, the contact book or the calendar, and contain no code that reads them.

Push notifications

If a staff member allows notifications, the handset receives a token from Apple or Google. We store it against that staff account so a shift change reaches the right phone, together with the platform, app version and language. Notifications carry an event and a room number — never an identity document, a folio or a guest's identity number. Turning notifications off in the operating system, or signing out, ends the registration.

No tracking, no advertising

The apps contain no advertising identifier, no advertising SDK and no cross-app or cross-site tracking. They never present the App Tracking Transparency prompt because there is nothing to ask for. Nothing they collect is shared with a data broker or combined with data from another company's apps or websites.

What the store labels say

The data types declared on the App Store and Google Play match this policy: contact details, identity and stay records, purchase and financial records, account and device identifiers, and free-text notes — all linked to an account, all used solely to make the app work, none used for tracking. Crash and performance reports are declared separately and are not linked to any identity.

The Service reports its own crashes and errors to Sentry so that a fault a receptionist hits at 2 a.m. is visible to us rather than silently endured.

These reports are configured to carry no personal data. Screenshots and view-hierarchy capture are disabled, session replay is disabled, and the sending of default personal identifiers — including the network address and the signed-in user — is disabled. Query strings are stripped from every recorded network address before an event leaves the device, so a database filter such as a guest's phone number cannot travel inside a stack trace.

What a report contains is the error, where in the code it happened, the app version, the device model and the operating system version. It is not linked to a staff account or to a guest.

Reports are retained by Sentry for 90 days and then deleted.

Inside the Service

The web application, and the iOS and Android apps, set only what they need to work: a session token so a signed-in user stays signed in, and local storage for the chosen language, the light or dark theme, notification preferences and the remembered property code. There is no advertising cookie and no cross-site tracking anywhere in the Service. None of this is optional, and none of it is used to observe behaviour.

On the public marketing pages

Four pages are public: the English home page, the Turkish home page, and these two legal pages. On those pages only, and only after the visitor has actively consented through the cookie banner, we load Google Analytics, the Meta Pixel and its conversions interface, and PostHog, to measure how well our own advertising works. Vercel Analytics collects aggregate page counts without cookies.

Nothing is loaded before consent is given — the tags are not injected at all until the choice is made, rather than loaded and asked about afterwards. A refusal is remembered, so the banner is not shown again on the next visit. Consent can be withdrawn at any time by clearing site data for anynamehotel.com in the browser.

These tags never run on any signed-in page. Hotel staff at work are not an advertising audience, and the screens they use carry guest names.

If a visitor arrives from an advertisement, the campaign identifiers in the link are held in that browser for the length of the visit and are sent to us only if the visitor chooses to submit the demo form — at which point they are asking to be contacted.

Data is hosted in Supabase and Vercel data centres, which may sit outside Türkiye and outside the European Economic Area.

Under KVKK art. 9 a transfer abroad needs its own lawful ground. We rely on the written undertakings and standard contractual terms in place with those providers, and on the appropriate safeguards under GDPR art. 46 where it applies. A hotel may ask us which mechanism applies to it and we will say.

A hotel that needs its data to stay in a particular region should raise it before onboarding, so that we can tell it whether we can meet that.

•Guest and stay records: until the hotel deletes them or closes its account. Records that are relevant to accounting are kept for as long as the hotel's own statutory retention duty requires.

•After an approved account closure: 30 days in which nothing is deleted and the hotel can still cancel, then erasure from the live database, then removal from encrypted infrastructure backups within a further 30 days.

•After a licence expires or is suspended for non-payment: 90 days from expiry, so that renewing restores everything intact; deletable after that, and we write to the owner account before we delete.

•Website and in-app enquiries: 24 months from the last contact, unless the sender asks us to delete them sooner.

•Support messages: 24 months, so that the history of a problem can be seen.

•Account-closure and data-export requests, with our decisions on them: 5 years, as proof of what was asked and what we did.

•Error and performance reports: 90 days.

•Push device registrations: until the device is unregistered, the staff account is removed, or the token is rejected as stale.

Identity reports already transmitted to the authorities live in their systems, not ours, and are not recalled by closing an account here.

Access is authenticated per staff account and separated by role. Every property's rows are isolated at the database level by row-level security, so that one property cannot read another's — the isolation is enforced by the database itself and not only by the application.

Traffic is encrypted in transit with TLS, and data is encrypted at rest by our infrastructure providers. Passwords are stored only as salted hashes and are not readable by us.

Operational actions are written to an append-only log that records who did what and when. Administrative access on our side is limited to named individuals and is reviewed.

No system is perfectly secure. We keep our dependencies patched, review the security posture of the platform periodically, and act on what those reviews find.

If we discover a breach that affects a hotel's data, we tell the owner account without undue delay once we have enough to describe it — what happened, which data is involved as far as we know, what we are doing about it, and what the hotel should do.

As the data controller, the hotel is the one that notifies the Personal Data Protection Authority and, where required, the people affected. Under Board decision no. 2019/271 that notification is due within 72 hours of the hotel becoming aware. We give the hotel the information and the reasonable assistance it needs to meet that deadline.

Where we are the controller — enquiries, support messages, account and billing records, diagnostics — we notify the authority and the people affected ourselves, within the same deadlines.

Under KVKK art. 11 and, where it applies, the GDPR, a person may ask whether their data is processed, ask what it is used for and who it has been passed to, ask for a copy or for portability, ask for correction of what is wrong, ask for deletion, object to processing, ask for the consequences of correction or deletion to be passed on to third parties, and claim compensation for damage caused by unlawful processing.

How to exercise them

Guests should address the hotel that recorded their stay. It holds the relationship and can view, correct, export or delete the record itself inside the app, without needing anything from us. If a request reaches us first, we pass it to the hotel and help them act on it.

Staff of a property, and hotels asking about their own account, can write to support@anynamehotel.com. We answer within 30 days, which is the KVKK art. 13 deadline; where the GDPR applies we answer within one month.

We may ask for enough information to be satisfied of an applicant's identity before we act. That is a safeguard for the applicant, not an obstacle, and we ask for the least we can.

Anyone who is not satisfied with our answer may complain to the Personal Data Protection Authority (Kişisel Verileri Koruma Kurumu, kvkk.gov.tr) or, under the GDPR, to their local supervisory authority.

The Service is a staff tool. It is not offered to, marketed to, or intended for children, and we do not knowingly collect data from a child as a user.

A guest record may include a minor travelling with their family, because accommodation law requires every guest to be registered. The hotel is the controller of that record and is responsible for it as for any other guest record.

Updates appear at this address with a new version number and date. The previous version is available on request.

Material changes are announced to the owner account of each property before they take effect. Where a change requires consent, we ask for it rather than assuming it.