Privacy Policy

Takt Kabinet Service · edition of October 6, 2026

This Policy describes the processing of personal data in two products: the public booking form (the /book/ page, available via a link with a secret key) and the landlord’s Telegram bot, including the Google Calendar integration.

The form requires no registration: no account is created, no password is entered, and the tenant’s identity is not verified. At the same time, the name and contact details that tenants provide themselves (especially a phone number or Telegram username) directly or indirectly identify them, and are therefore processed as personal data to the full extent of this Policy. Without these details a booking is impossible — they are required fields of the form.

1. Who the operator is

The Service operator: Oleg V. Ageev, self-employed individual, TAX ID (INN) 110307254043.

Processing is carried out on servers of the Beget hosting provider (Russia). This Policy covers all stages of processing (collection, storage, transfer, deletion).

If you have any questions about this Policy, contact us at: bealright.support@gmail.com

2. What data we process

• Tenant (visitor of the booking form):
  • name — as entered in the form (up to 200 characters);
  • contact details in free form — phone number, Telegram username, e-mail (up to 200 characters), plus their normalized service variant (case and format reduced to a single key). The normalized contact serves a single purpose: matching your bookings with each other on the service side when office rules are checked. There is no separate tenant profile, and the contact is not used for marketing or analytics;
  • booking data: office, date and time, duration, composition of the repeat series, booking status; the secret management link — a random token issued to the tenant after booking as the only way to view, reschedule and cancel the booking (a pseudonymous identifier containing no identity data);
  • technical data: IP address, time, method and path of the HTTP request, response status — in access logs and the rate-limiting subsystem.
• Landlord (office owner, bot user):
  • Telegram data: user/chat ID, display name; the list of the landlord’s operators and their binding to the landlord;
  • Google account data: Google account address, OAuth access and refresh tokens, identifiers of the connected calendars, the write-mode flag;
  • calendar event projection: event ID, title, start and end time, organizer’s e-mail, attendee addresses, recurring-series flag, Google service timestamps; the service-side synchronization cursor;
  • office data: name, address, time zone, booking window, peak hours, rules;
  • notification history: which message was delivered to which chat and when (for subsequently editing “conflict resolved” messages).
• Tenant data that ends up in the landlord’s environment (not a separate collection — a consequence of how the form works, see section 3):
  • the tenant’s name — in the title of the event created in the landlord’s Google Calendar;
  • the tenant’s contact details — in that event’s description;
  • the name, contact details and time of the booking — in notifications delivered by the bot to the landlord’s operators.

3. Why we process data

For each category of data — the purpose of processing and its legal basis:

• 3.1. Tenant’s name and contact details — creating the booking and enabling communication between landlord and tenant: the tenant has no other communication channel. Basis: performance of the tenant’s request (conclusion and performance of the rental agreement);
• 3.2. Normalized contact — a service-side “same tenant” check: booking with a 30-minute gap during peak hours is prohibited by the office rules. Basis: performance of the request;
• 3.3. Booking data — displaying availability, rescheduling, cancellation, prevention of double bookings. Basis: performance of the request; the landlord’s legitimate interest;
• 3.4. Secret link — booking management by the tenant without registration; combining a repeat series into a single management link. Basis: performance of the request;
• 3.5. Landlord’s Telegram data — delivering notifications: new, rescheduled and deleted events, conflicts, confirmations, synchronization stoppage. Basis: performance of the agreement with the landlord; consent;
• 3.6. OAuth tokens and calendar data — creating events in the landlord’s calendar and maintaining synchronization: up-to-date availability, detection of conflicts and deletions. Basis: consent, revocable by disconnecting the integration;
• 3.7. Office settings — operation of the form and enforcement of the office rules. Basis: performance of the agreement with the landlord;
• 3.8. IP addresses and access logs — protection against key guessing and abuse, rate limiting, failure diagnostics. Basis: legitimate interest (security);
• 3.9. Metrics — health monitoring: aggregated counters only, no personal data. Basis: legitimate interest.

An important consequence: by creating a booking, the tenant instructs Takt Kabinet to pass their name and contact details to the landlord — via an event in the landlord’s Google Calendar and notifications to its operators. The landlord acts as an independent recipient of this data and processes it for their own purposes (booking-related communication, cancellation rules).

We do not sell user data and do not use them for advertising or for building advertising profiles.

4. Google data

The Google Calendar integration is optional: you connect it yourself in the bot and can disconnect it at any time.

Limited Use. Data received by Takt Kabinet through the Google API are used only to provide and improve the schedule synchronization features visible to you. We do not sell this data, do not use it for advertising, and do not pursue any purposes unrelated to the operation of the Service. Transfer to third parties is possible only as processing on our behalf by infrastructure providers (hosting) — solely for the operation of the Service and not for their own purposes. Calendar event data (title, time, and booking details) are sent to the landlord through the Telegram Bot API solely to deliver the notifications the landlord has enabled. This is a user-facing feature of the app and is not a transfer for any other purpose. This use complies with the Google API Services User Data Policy, including the Limited Use requirements.

Takt Kabinet’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.

We do not allow humans to read Google user data unless we have the user’s explicit consent for specific data, it is necessary for security purposes (such as investigating abuse), to comply with applicable law, or the data is aggregated and anonymized.

5. How we store data

5.1. Where. Data are stored in a PostgreSQL database on a server of the Beget operator (Russia). The application and the database are isolated within a Docker environment: the database is not accessible from the internet and is administered only by the Service administrator. Backups to Yandex Disk are created daily on schedule; their retention period is 60 days, after which they are deleted automatically.

5.2. Protection of secrets.

• the booking management link is a random token generated by a cryptographic generator (192 bits of entropy). It is issued to the tenant once and is the only way to manage the booking; guessing the link is practically impossible;
• service responses containing availability and booking data are marked Cache-Control: no-store — they are not stored in browser caches or on intermediate nodes;
• Google OAuth tokens are stored separately in the database, are used exclusively for calls to the Google API on your behalf, are never written to logs and are never included in error messages;
• key guessing and abuse are rate-limited by IP address; rate-limit counters are kept in process memory and are never written to disk.

5.3. Calendar projection. Events of the connected calendar are stored in a sliding window: 180 days forward from the current date plus 7 days back. Upon reconnection or a change of calendar, everything outside the new window is deleted automatically; upon complete disconnection of the integration, the event data, synchronization cursors and the token are deleted immediately (see the “Google data” section).

5.4. Access logs. Technical logs (IP address, time, request method and path, response status, duration) are kept for 7 days and are used only for security and failure diagnostics.

5.5. Retention periods for other data.

• active bookings — until they end or are cancelled. Cancelled and expired bookings are kept in a service form until a deletion request: they are inaccessible via the management link and do not block availability;
• landlord data — while their connection with the Service is active; after the connection or account is deleted, the data are deleted within 30 days upon request;
• upon a data subject’s request, data are deleted earlier than the established period — see the “Your rights” section.

5.6. Automated decisions. Availability checks, peak-hour rules and calendar event matching are performed automatically, but they create no profiles and make no judgments about a person: the only possible effect is the refusal of a specific overlapping slot or a requirement to choose a different time within the office rules.

6. Sharing data with third parties

• Google (Calendar API) — upon OAuth connection: the tenant’s name and contact details as part of the created event; the landlord’s calendar data — during synchronization, strictly under the landlord’s own Google account;
• Telegram (Bot API) — at the landlord’s request, to deliver notifications to their operators; the notifications may contain the tenant’s name, contact details and booking time;
• The landlord — the tenant’s name and contact details (section 3.1): into their calendar, into notifications to their operators, and, with manual integration, into their own booking system;
• Hosting provider — storage infrastructure (processing on our behalf).

There are no other transfers. We do not sell data and do not transfer them for advertising purposes.

7. Security

We apply reasonable organizational and technical protection measures:

• traffic between you and the Service is transmitted over HTTPS;
• the database is not accessible from the external network; only the Service administrator has access to the data.

The protection of booking management links and OAuth tokens, as well as rate limiting of key guessing and abuse, are described in section 5 “How we store data” (clause 5.2).

8. Your rights

You may request access to your data, as well as their rectification, deletion or restriction of processing — write to bealright.support@gmail.com. We will respond within 10 business days.

Some actions are available immediately, without a request:

• the tenant can view, reschedule or cancel the booking via the management link — upon cancellation the event is removed from the landlord’s calendar, and the service record of the booking is retained as described in section 5 “How we store data”;
• the landlord can disconnect the Google Calendar integration in the bot (the token and the stored calendar data are deleted immediately) and revoke the booking form keys.

9. Changes to this Policy

Upon material changes to the Policy, we will update the edition date on this page and, where appropriate, notify you with a message from the bot. By continuing to use the Service after the changes take effect, you accept the updated edition.

10. Contacts

Any questions about data and this Policy: bealright.support@gmail.com