Privacy Policy

This Privacy Policy explains how Appointmentist (“Appointmentist”, the “Service”, “we”, “us”, or “our”) collects, uses, shares, and protects personal data when you use our website, web app, booking pages, membership card pages, Telegram bot and Mini App, and related services.

In short. Appointmentist reads the calendars you connect, read-only, to show your schedule, find the appointments that need a follow-up, remind you, and keep your client list. It writes to a calendar only if you turn writing on, which asks for a separate permission at that moment. AI runs on its own only after you turn on “Use AI for scheduling”; other AI features run when you press their button. We contact your clients only when you send a text or call, when your booking page is set to send booking notices, and with the automatic replies to STOP, START, and HELP. We never sell your data, and we never use it for advertising or to train AI models. We encrypt client and appointment data at rest, and you can unlink an account (keeping one way to sign in) or delete your account at any time.

1. Who we are

Appointmentist is operated by Individual Entrepreneur Dmytro Andriyovych Nelipa (ITIN 3718211418), Kyiv, Ukraine. Under the EU and UK General Data Protection Regulation (“GDPR”) and similar laws, we are the controller of the personal data about you as a user of the Service: your account, your settings, your billing, and how you use the Service.

For personal data about other people that you or your business put into the Service (your clients and their contacts, the people who book through your booking page or carry your membership cards, and your staff), your business is the controller, and we process that data on its behalf and under its instructions as a processor (see section 5).

If you have any questions about this Policy or how we handle your data, contact us at [email protected].

2. Scope of this Policy

This Policy applies to personal data we process when you visit ppt.ist, use the web app at business.ppt.ist (in a browser or installed as an app), connect a calendar, set up reminder channels, publish a booking page (reserve.ppt.ist) or membership cards (membership.ppt.ist), or use our Telegram bot and Mini App.

If you are a client of a business that uses Appointmentist, for example because you booked through its booking page or carry its membership card, that business decides how your data is used, so please contact it first. This Policy explains what we do with your data on its behalf.

This Policy does not apply to third-party services you connect to or are redirected to, such as Google, Microsoft, Telegram, or a payment provider. Each is governed by its own privacy policy.

3. Information we collect

Depending on which features you use, we collect the following.

a. Account and identity

• Sign-in identifiers: the account ID (the OpenID Connect sub), email address, and name that Google or Microsoft shares when you sign in or link an account.
• Telegram identity: if you sign in with Telegram or open the Mini App, your Telegram user ID, name, username, and profile photo link.
• Settings and preferences: your time zone, follow-up settings, scan range, AI instructions, notification choices, and the answers you give during setup.

b. Connected accounts and authorization data

• OAuth tokens: the access and refresh tokens your calendar provider issues, the permissions you granted, and when the tokens expire. Tokens are encrypted at rest and stay on our servers. The one exception is a short-lived access token on an end-to-end encrypted workspace, explained in section 8.
• Calendar choices: which calendars you chose for the Service to read and, if you turned writing on, the calendar it writes to.

c. Calendar data

• The events in the calendars you choose: titles, descriptions, locations, start and end times, the organizer, attendee email addresses, when each event was created and changed, and identifiers that link repeating events. These often include personal data about other people, such as your clients. Section 5 explains how we handle it.
• On an end-to-end encrypted workspace, some or all of these details are sealed so that only your team can read them. In the strictest setting, our servers receive only appointment times.

d. What you and your team put into a workspace

• Clients: names, phone numbers, email addresses, related contacts, service history, notes, and files attached to notes.
• Follow-ups: reminders and their text and timing, matching rules, templates, groups, services, and the details AI picks out of an appointment.
• Team: the members of a workspace and their permissions. For staff: working hours, shifts, time off (including sick leave), the services they provide, their pay rates, and the pay calculated for each period.
• Booking pages: your page’s services, prices, and hours, and for each booking what the visitor entered (name, phone number, email address, notes, and answers to your booking form), plus any deposit and its status.
• Membership cards: your programs with their tiers and benefits, and for each card its points, visits, and spend, and the client it is attached to, if staff attach one.
• Public profile: if your business creates a public directory profile, its address, description, and map pin.

e. Messages to your clients

• Texts sent from your workspace, the replies that come back, their delivery status, and records of calls placed.
• Records of who agreed to receive texts and who asked to stop (see section 11).

f. Reminder channels

• Telegram: your chat ID and chat type with our bot, and the topic we open in that chat for each workspace (or the details of a private bot, if your workspace set one up earlier).
• Browser notifications: your browser’s push subscription (an endpoint address and keys).
• Delivery records: which reminders went to which channel, and whether delivery worked.

g. Billing and payment data

• If you buy a subscription: your plan and billing period, invoice and transaction identifiers, amounts and currency, payment status, the name and email address on the invoice, and your card’s brand, expiry date, and masked number (for example, 424242******4242). To renew your subscription, we keep the card token the payment processor gives us, encrypted at rest. We never see or store your full card number, CVV, or PIN.

h. AI provider keys

• If you add your own AI provider API key, it is encrypted at rest (envelope encryption, with keys held in a separate key-management service), and we show only a masked hint (for example, sk-or-…ab12). Keys we issue for your workspace are stored the same way. On an end-to-end encrypted workspace that uses AI, a member’s browser may receive an AI key (section 8).

i. Technical and usage data

• Sessions: a server-side session referenced by an opaque, signed cookie, and the public half of a key your browser creates, so we can check that requests come from the device you signed in on. We don’t use passwords; your sign-in provider handles authentication.
• Operational data: request details, IP address, device and browser information, and server logs, used for security, abuse prevention, and reliability. To limit abuse of booking pages, we store a keyed code derived from the visitor’s IP address, not the address itself.

4. How we use your data & our legal bases

We use personal data for the purposes below. Where the GDPR applies, the legal basis is shown in brackets.

• Provide the Service: sign you in, read the calendars you choose, show your schedule, find the appointments that need a follow-up, keep your client records, create and schedule follow-ups, and deliver reminders to the channels you choose. [Performance of a contract]
• Features you turn on: show the open times on your booking page, based on when you are busy; write follow-up time, bookings, and the appointments you create to a calendar you allow; run your membership cards and staff schedules; and send the texts, calls, and booking notices you ask us to send. [Performance of a contract]
• AI features: when you turn them on or press their button (see section 7), sort appointments, pick out the client and service an appointment is about, and draft reminders and messages. [Performance of a contract / consent]
• Billing: process subscriptions, payments, refunds, and receipts. [Performance of a contract / legal obligation]
• Security and reliability: protect the Service and its users against fraud and abuse, limit sending rates, keep logs, and fix problems. [Legitimate interests]
• Service messages: tell you about your account and the Service, in the app and on the reminder channels you connect. [Performance of a contract / legitimate interests]
• Comply with the law: meet legal, tax, and regulatory obligations and respond to lawful requests. [Legal obligation]

We do not sell your personal data, and we do not use your calendar content, client data, or follow-up data for advertising or to train AI models.

5. Calendar & contact data

When you sign in with Google or Microsoft (Outlook and Microsoft 365, both in beta), or link another account, we ask for read-only access to your calendars (Google’s calendar.readonly scope; Microsoft’s Calendars.Read). With it, we read the list of your calendars so you can choose which ones to use, and the events in the calendars you choose. Unless you turn on writing, described below, we never create, change, or delete anything in your calendars.

We use the events we read to show your schedule, find the appointments that need a follow-up, keep your client records, and remind you. If you publish a booking page, we also use the times you are busy, so the page offers only times you are available. The page shows those open times, never your events.

Writing to a calendar (optional, off by default)

You can let the Service write to a calendar: to block out the time your follow-ups will take, where you will actually see it; to add bookings made through your booking page; and to add appointments you create in the Service. This is off unless you turn it on, and turning it on asks for an extra permission at that moment, never during sign-in. There are two options:

• A calendar of its own (recommended). We create one new calendar and write only there. On Google this uses the calendar.app.created scope, which lets us change only calendars the Service created; it gives no permission to change any calendar you already had. (We can still read the calendars you chose, under the read-only access above.)
• One of your existing calendars. If you pick a calendar you already use, Google needs the broader calendar.events scope, which allows editing events in your calendars. We use it only to add, update, and remove the events the Service places there, and never to change or delete events we did not create.

Microsoft (Outlook and Microsoft 365, both in beta) offers no permission limited to one calendar, so either option asks for Calendars.ReadWrite, which covers all your calendars. We still write only to the calendar you chose.

A follow-up time block has a title and a duration. You choose how much each block says: only that you are busy, what kind of work it is and how much, or, where the Service can read them, who each follow-up is about. On an end-to-end encrypted workspace we cannot read those names, so that last option is not offered.

Turning writing off removes the blocks we created. You can also withdraw the permission in your provider’s account settings at any time (see section 14); the Service then stops writing and tells you.

Google API Services — Limited Use disclosure

Appointmentist’s use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. In particular, Google user data is used only to provide the user-facing features you use or turn on, as described in this Policy; it is not transferred to third parties except as necessary to provide those features (see “How we share data & our subprocessors” below), with your consent, or where required by law; it is never sold, never used for advertising, and never used to train generalized artificial-intelligence or machine-learning models. Humans do not read this data except with your explicit permission, where required for security or legal compliance, or after it has been aggregated and anonymized.

Data about other people

Your events may contain personal data about other people, most often attendee email addresses, and your workspace holds data about your clients, your booking page visitors, your card holders, and your staff. For that data we act as a processor: we handle it on your behalf and under your instructions, only to provide the features you use or turn on. You are responsible for having an appropriate basis to share these people’s data with the Service. We do not contact them, market to them, or use their data for our own purposes; any message they get from the Service is one your business sends or has set up.

6. Permissions we ask for, and your choices

Every sign-in asks your provider for the same set of permissions. Anything more is asked for only when you choose a feature that needs it. Your provider’s consent screen shows each request, and you can approve or decline it there.

Google

• openid, email, profile: asked for at every sign-in and account link, so we know it’s you. We receive your Google account ID, email address, and name.
• calendar.readonly: asked for at every sign-in and account link. It is read-only: we use it to list your calendars so you can choose which ones to use, and to read the events in the calendars you choose, including notices when they change.
• calendar.app.created: asked for only when you turn on writing and choose “A calendar of its own”. We use it to create the Service’s own calendar, and to add, update, or remove the events we place there.
• calendar.events: asked for only when you turn on writing and choose “One of my calendars”. We use it to add, update, or remove the events we place in the calendar you picked.

Google names these three calendar permissions in full as follows:

Microsoft (Outlook and Microsoft 365, both in beta)

• openid, email, profile: asked for at every sign-in and account link, so we know it’s you. We receive your Microsoft account ID, email address, and name.
• offline_access: asked for at every sign-in and account link. We use it to keep reading your calendars in the background, without asking you to sign in again.
• Calendars.Read: asked for at every sign-in and account link. It is read-only: we use it to read your calendars and their events, including notices when they change.
• Calendars.ReadWrite: asked for only when you turn on writing, whichever option you choose. We use it to create the Service’s own calendar, or to write to the calendar you picked. Microsoft offers no narrower permission for this.

Telegram

• openid, profile, telegram:bot_access: asked for when you sign in with Telegram. We receive your Telegram user ID, name, username, and photo, and permission for our bot to send you messages.

What you can do

• Approve or decline. Google shows calendar access as a separate item on its consent screen, and you can leave it unticked. You can still sign in, but the Service cannot read your calendars until you connect the account again and allow it. Microsoft asks for its permissions together; for a work or school account, your organization’s administrator may need to approve the app first.
• Writing is asked for separately. If you decline the writing permission, writing stays off.
• Choose which calendars we read. You can switch any calendar on or off at any time, and we stop reading a calendar you switch off.
• Choose how much we write and send. You decide what each calendar block says (section 5) and what reminders say (section 9).
• Keep AI off, or turn it off. “Use AI for scheduling” is off until you turn it on (section 7).
• Unlink an account. Unlinking deletes the tokens we hold for it and the appointments we read through it. You need to keep at least one way to sign in (section 14).
• Remove the permission at your provider. You can withdraw access in your Google or Microsoft account at any time (section 14).
• Keep appointment details off our servers. An end-to-end encrypted workspace can choose a setting in which our servers receive only appointment times (section 8).

7. AI processing

AI is optional. We send data to an AI provider only in these cases:

• Automatic AI, which you turn on. With “Use AI for scheduling” turned on in AI settings (it is off by default), AI reads each new appointment against your rules as your calendars are scanned, picks out the client and service it concerns, and writes the reminder text. It also turns what it learns from your decisions into a short note about each calendar. On an end-to-end encrypted workspace, automatic AI also needs “AI under end-to-end encryption” to be turned on. With either switch off, scans use only your rules.
• AI you ask for. When you press an AI button, that one request is sent: for example, to let AI decide the suggestions you selected (“Delegate to AI”), write rules from your description, draft a message or call script for a client (“Suggest with AI”), summarize a client’s history (“Summarize with AI”), draft a rule’s follow-up instruction (“Draft with AI”), find the appointment you describe, or group or refine your reminders. The setup chat sends each message you write in it.

Which AI features you can use depends on your plan and on whether you add your own AI provider key.

What is sent: only what the feature needs. Typically that is an appointment’s title, description, location, time, attendees, and organizer; your rules and instructions; and, for a message to a client, that client’s details and the past appointments you opened. Before sending, we replace the names and contact details we recognize with placeholders, and put them back into the answer when it returns. We keep no copy of what we send to the AI provider. What you type into an AI feature, and the results, such as reminders, rules, and drafts, are saved in your workspace.

Who receives it:

• AI we provide goes through OpenRouter, which we instruct on every request to use only providers that keep no copy of the data and do not collect it; or through Google AI Studio (the Gemini API), under Google’s terms for paid services, under which Google does not use prompts or responses to improve its products and keeps them for a limited time only to detect abuse and meet legal requirements.
• With your own key, your requests go to the provider you chose, under your agreement with it. With your own OpenRouter key, we send the same instruction to use only providers that keep and collect nothing. If you add a Google AI Studio key, use one from a Google Cloud project with billing turned on: Google’s terms let it use content sent with unpaid keys to improve its products and have people review it.

On an end-to-end encrypted workspace, a member’s browser may send AI requests to OpenRouter directly (section 8).

8. End-to-end encrypted workspaces: what your browser holds

A workspace can turn on end-to-end encryption on plans that include it. Its members’ browsers then hold the keys: each member unlocks them with a passphrase, and the browser keeps them in memory only while the app is open. We store the protected data only in encrypted form that our servers cannot open. What is protected depends on the setting the workspace chooses:

• Keep automatic scanning (recommended): client records, contacts, and notes are end-to-end encrypted. Appointments and reminder text stay readable to our servers, so scanning, scheduling, and full reminders keep working.
• Seal everything: appointments and reminders are sealed too. Our servers still read each new appointment briefly in memory to seal it as it arrives, and new appointments wait for a member’s browser to process them.
• Seal everything, and never send details here: our servers receive only appointment times. The member who connected each calendar fetches the details in their own browser and seals them there.

In every setting, service names stay readable to our servers. If a workspace lets our servers match its rules, a copy of those rules and templates is kept where our servers can read it.

When a token or key reaches your browser

Everywhere else in this Policy, calendar tokens and AI keys stay on our servers. End-to-end encryption makes two deliberate exceptions, so that appointment details can bypass our servers:

1. Calendar access in the strictest setting. On “Seal everything, and never send details here”, the browser of the member who connected a calendar receives a short-lived access token for that calendar account. It uses the token to fetch appointment details from Google or Microsoft directly and seals them before anything is sent to us. Only that member can get the token. The refresh token, which is what lets us get new access tokens, never leaves our servers.
2. AI under end-to-end encryption. When a workspace has turned on “AI under end-to-end encryption”, a member’s browser can send AI requests to OpenRouter directly instead of through our servers. It receives either a temporary key we create for that member, which expires after 30 minutes and has a small spending limit, or, if the workspace uses its own OpenRouter key, that key itself. Only the workspace owner and members with the “Manage clients & services” permission can receive it. AI that runs through Google AI Studio, or on a key we share across workspaces, keeps going through our servers.

Why this is safe, and where its limits are:

• The token or key reaches the browser only in answer to a request signed with that device’s own key, over a connection that is encrypted a second time inside TLS.
• The browser keeps it in memory, uses it only for that task (a calendar token only with Google Calendar or Microsoft Graph, an AI key only with OpenRouter), and never stores it.
• A calendar access token stops working on its own soon after it is issued, and a temporary AI key expires after 30 minutes.
• While it is in the browser, it carries the access it was issued for. Anything that took over that browser tab could use it, just as it could use your open session. Encryption also relies on the app code we serve: it cannot protect you from a version of the app built to hand your keys over.
• Your own OpenRouter key does not expire, and any member who receives it could copy it. Grant “Manage clients & services” only to people you trust with that key, and replace the key if one of them leaves.

9. Reminders on Telegram and in your browser

• Telegram. Appointmentist has one Telegram bot for everyone. When you connect Telegram, reminders arrive in your private chat with our bot, and each workspace gets its own topic there, named after the workspace. We store your chat ID and chat type, and the topic we opened for each workspace. The Mini App also keeps the list of your workspace topics (their IDs and names) in Telegram’s cloud storage for your Telegram account. A workspace that set up its own private bot earlier can keep using it.
• Group chats. A workspace’s own private bot can also be connected to a group chat. Connecting a group is the decision, and the responsibility, of the workspace owner or the member with the “Manage notification channels” permission who connects it. Everyone in that group can read what the reminders say, so choose the group, and what reminders say, with its members in mind.
• Browser notifications. If you turn them on, we send each notification through your browser’s push service, encrypted so that the push service cannot read it.
• What reminders say. Under “What notifications say” in your follow-up preferences, you choose whether a notification says only that something is due, with a link into the app; when the appointment was and when the follow-up is due; or everything, including who it is about, their contact details, and notes. On the sealed end-to-end encryption settings, notifications can only carry a link.

Messages delivered to Telegram leave the Service and are kept by Telegram under its own privacy policy.

10. How we share data & our subprocessors

We share personal data only as needed to run the Service. The table lists each kind of recipient, the services we use for it, what they receive, and when. We do not sell your data.

We may also disclose data to professional advisers, to a successor in a merger, acquisition, or sale of assets, or where required to comply with law, enforce our terms, or protect the rights, safety, and security of users and the public.

Inside your workspace and on your public pages. Members of a workspace see what their permissions allow. What a business publishes is public: its booking page shows its name, services, prices, and open times (never its calendar events), and a membership card’s page shows the card’s public details.

Our staff. A small number of authorized staff can open your account in a support session to fix a problem: when you ask for help, or where needed for security or legal compliance. A support session lasts at most one hour and is recorded in our audit log. Staff cannot open end-to-end encrypted content, because they don’t hold your keys.

11. SMS/MMS messaging compliance

If you send texts or automated calls to your clients from the Service, or your booking page is set to send booking notices by text, we deliver them through Twilio, using our account or your own if you connect it.

• Non-sharing of mobile numbers: We do not share your clients’ mobile phone numbers with any third party for marketing, advertising, or any purpose other than delivering the specific message you asked us to send. The numbers are used solely to route the message via Twilio.
• Opt-in data: No mobile information will be shared with third parties/affiliates for marketing/promotional purposes. All the above categories exclude text messaging originator opt-in data and consent; this information will not be shared with any third parties.
• Consent records: We record when a client agrees to receive texts (for example, on your booking form) and when they ask to stop. We look these records up by a code derived from the phone number; where a record keeps the number itself as evidence, it is encrypted.
• When texts go out: A text or call goes out only when you send it, or when your booking page sends a booking notice. A text you send to a client needs a record of that client’s consent, and goes out only between 8:00 and 21:00 (8:00 and 20:00 for numbers that start with +1) in your workspace’s time zone. Booking notices go to the number the client gave for that booking, at any hour. Replies to STOP, START, and HELP are sent automatically. We do not send marketing messages of our own to your clients.
• Opting out: A client who replies STOP gets no more texts until they reply START.
• Message and data rates: Please note that message and data rates may apply. Your mobile carrier may charge you for receiving SMS or MMS messages. Appointmentist does not control these carrier charges, and we are not responsible for any costs incurred by you or your clients for receiving these messages.

12. International data transfers

We operate from Ukraine. Our servers are hosted by OVHcloud, and our database backups are stored in the EU. Several of the services in section 10 process data in other countries, including the United States, which may not offer the same level of data protection as your own. Where the GDPR or UK GDPR requires it, we rely on appropriate safeguards for these transfers, such as the European Commission’s Standard Contractual Clauses or an equivalent mechanism.

13. Data retention

We keep personal data only as long as we need it for the purposes in this Policy:

Deleted data can remain in database backups for about two weeks, until the backups that hold it are replaced. Our staff can also make an encrypted full backup by hand, for example before a major upgrade, and delete it once it is no longer needed for recovery. If a law requires us to keep a particular record for longer, we keep only that record, and only for as long as required.

14. Signing out, unlinking, and deleting your account

• Sign out ends your session on the device you’re using. Sign out of all devices, in Preferences, ends every session you have. Signing out does not disconnect your calendars: the access you granted stays in place, so scans and reminders keep running while you’re away.
• Unlinking a calendar account (Google or Microsoft) deletes the tokens we hold for it and the appointments we read through it. You need to keep at least one way to sign in, so add another account or Telegram before unlinking your only one.
• Deleting your account closes it at once: you are signed out on every device, and your paid plans are paused. Thirty days later we permanently delete your account and the workspaces you own, with everything in them, including your stored tokens. Signing in before then cancels the deletion. To have Google or Microsoft drop the permission right away, remove it yourself as shown below.

What each provider allows when you unlink it, and how to remove the permission yourself:

• Google. We ask Google to revoke the access you gave us, which ends Appointmentist’s access to that Google account, and we delete our copy of the tokens. If Google doesn’t respond, we still delete our copy. You can also remove the access yourself on your Google Account’s third-party access page.
• Microsoft (Outlook and Microsoft 365, both in beta). Microsoft offers no way for us to withdraw the permission for you, so we delete our copy of the tokens, which means we can no longer use them. The permission stays listed in your Microsoft account until you remove it: for a personal account, at account.live.com/consent/Manage; for a work or school account, in My Apps. A permission your administrator granted for everyone can be removed only by the administrator.
• Telegram. We hold no Telegram token, so there is nothing to revoke; we remove the link to your Telegram account. To stop reminders, disconnect Telegram in the app, or block our bot in Telegram.

15. How we protect your data

We apply technical and organizational measures appropriate to the risk, including:

• Encryption in transit with TLS, between your browser, our edge network, and our servers.
• Encryption at rest: client and appointment data is encrypted field by field with authenticated encryption, under data keys that are themselves protected by master keys held in a separate key-management service. OAuth tokens, AI provider keys, and card tokens are encrypted as well.
• Key rotation: the master keys are replaced about every 90 days, and the data keys are re-wrapped under the new master key. The keys that protect stored tokens rotate too, and stored tokens are re-encrypted under the new key.
• Sessions: a server-side session referenced by an opaque, signed cookie that scripts on the page cannot read, with protection against cross-site request forgery. Sensitive actions also need a proof signed with your device’s own key, so a copied cookie alone is not enough. Sign out ends your session on our side, and Sign out of all devices ends all of them.
• Tokens stay on our servers: your browser never holds your provider credentials or our client secrets, and holds a token or key only in the two end-to-end encryption cases in section 8.
• Standard OAuth hardening: Authorization Code flow with PKCE, signed and verified state, and sign-in tokens verified against the provider’s published keys.
• Logs without content: our server logs are set to leave out appointment content, contact details, and AI prompts.
• Staff access: our staff sign in to our operator console with an emailed link and a code from an authenticator app, and what they do there is recorded in a signed audit log.

No method of transmission or storage is completely secure, so we cannot guarantee absolute security. If we become aware of a personal data breach that affects you, we will notify you and the relevant authorities as required by law.

16. Your rights & choices

Depending on where you live, you may have some or all of the following rights regarding your personal data:

• Access — request a copy of the personal data we hold about you.
• Rectification — correct inaccurate or incomplete data.
• Erasure — request deletion of your data (“right to be forgotten”).
• Restriction & objection — restrict or object to certain processing, including processing based on legitimate interests.
• Portability — receive your data in a structured, machine-readable format.
• Withdraw consent — where processing is based on consent, withdraw it at any time without affecting prior processing.

You can exercise many of these rights directly in the app: unlink an account, remove a reminder channel, change what reminders say, turn off “Use AI for scheduling” or remove your own AI key, or delete your account. To make any other request, including for a copy of your data, contact us at [email protected]. We will respond within the time required by applicable law. You also have the right to lodge a complaint with your local data protection authority.

If you are a client of a business that uses Appointmentist, please send requests about your data to that business; we will help it respond.

California residents: we do not sell or share personal information as those terms are defined under the CCPA/CPRA, and you may exercise your rights to know, delete, correct, and not be discriminated against by contacting us at the address above.

17. Cookies & local storage

We use only what the Service needs to work and to remember your choices. We use no advertising or cross-site tracking cookies.

• Cookies: a session cookie that keeps you signed in, a companion cookie that protects against cross-site request forgery, and a language cookie that remembers your language for a year.
• Browser storage: the device key used to prove that your requests come from this device; a temporary copy of the data on the screens you open, kept only while that browser tab is open and cleared when you sign out (on an end-to-end encrypted workspace, this copy stays encrypted); and small preferences, such as whether the sidebar is open or which announcements you dismissed.
• Installable app and notifications: a service worker and, if you turn on browser notifications, a push subscription.
• Telegram’s Mini App script, loaded from telegram.org on app pages so the app works inside Telegram.
• Cloudflare Web Analytics, if turned on for our sites, counts visits without cookies.

Because the session and security cookies are essential, they can’t be turned off without breaking sign-in.

18. Children's privacy

The Service is for adults: you must be at least 18 years old to use it. We do not knowingly collect personal data directly from anyone under 18. If you believe a child has given us personal data, contact us and we will delete it.

19. Third-party services & links

The Service works with and links to third-party services such as Google, Microsoft, Telegram, Twilio, AI model providers, payment providers, and wallet apps. Your use of those services is governed by their own terms and privacy policies, which we encourage you to review. We are not responsible for the privacy practices of third-party services.

20. Changes to this Policy

We may update this Policy from time to time. When we make material changes, we will change the dates at the top of this page and, where appropriate, tell you in the app. If you keep using the Service after an update takes effect, the updated Policy applies.

21. Contact us

If you have questions, concerns, or requests about this Policy or your personal data, contact us at:

Individual Entrepreneur Dmytro Andriyovych Nelipa — Appointmentist

ITIN 3718211418

Kyiv, Ukraine

Email: [email protected]