Privacy Policy
Version 0.5 — last updated: 2026-10-05
Unreviewed draft. This text was written from how the application actually works, but it has not yet been checked by a lawyer. None of these documents is in force or applies to any subscription yet, and none should be relied on as the operative document.
This policy explains what personal data the Tá Marcado platform processes, on what legal basis, for how long it is kept and who it is shared with. It is written from how the application actually works: the periods, cookies and fields described here match what the system does. Tá Marcado is a service of GD Projects, Lda., Rua Dom Diniz, n.º 45, Burinhosa, Pataias, 2445-042 Pataias, freguesia de Pataias e Martingança, concelho de Alcobaça, distrito de Leiria, VAT 519433858.
1. Who we are and what this policy covers
Tá Marcado (tamarcado.pt) is an online booking platform that businesses — barbers, hairdressers, studios, practices and the like — use to publish their diary and take bookings.
This policy covers the management panel, each business’s public booking page, the customer’s private pages and the platform’s privacy journeys. The information website and external contact form have separate notices at /en/privacidade-website and /en/cookies-website.
It does not cover what each business does with data outside the platform, nor that business's own website, social media or systems.
2. The two roles: when we are the controller and when we are a processor
There are two different kinds of processing on this platform, and it matters not to confuse them.
Booking data. The business you book with is the one deciding to collect it: it defines the services, the schedule and the policies, and it is the data controller. We process that data on its behalf, as a processor, and only to provide it the service. The instructions and safeguards are in the Data Processing Agreement, which forms part of the contract with every business.
Account, subscription, billing, security and platform operation data. Here we are the controller in our own right: we decide what data is needed to keep accounts, charge the subscription, prevent abuse and keep the service running.
In practice: if you want to know why your contact details are in a business's diary, or ask for them to be erased from it, the business is the one to talk to, and we help it carry the request out. If the request is about your platform user account or about the subscription, then it is us.
3. Data about people who create an account and run a business
Creating an account requires an email address and a password. Authentication is handled by Google's Firebase Authentication, and that is where the email and password are stored — the password never reaches our server in readable form and is never stored by us.
The record we keep about a user in our own database is deliberately minimal: an opaque identifier, the date of the last sign-in and the schema version. The email is not copied into that record.
To bill the subscription we keep a billing profile with the name and country of the entity. The tax address and the VAT number, where provided, are collected and held by Stripe, which issues the charge and calculates VAT; they are not copied into our database. The account email is sent to Stripe so the customer can be linked to the charge.
We also store the link between each user and each business — the role, owner or worker — and, where applicable, which professional it corresponds to.
We never receive or store card details. Payment happens on Stripe's own pages.
4. Data about people who make a booking
To make a booking we ask for a name and one contact detail — email or mobile number. The language of the booking is stored, because every message about it is sent in that language. If you book more than once with different contact details, the customer record ends up holding both channels.
The booking stores an immutable snapshot of what was agreed: service, professional, duration, price, modality (in person or online) and the version of the business's policies in force at that moment. That snapshot contains neither your name nor your contact details: it points at the customer record through an opaque identifier.
The business can write internal notes about customers and bookings. Customer notes are visible only to owners; workers can only view notes on bookings in their own diary. These notes must not contain health data: the platform expressly prohibits clinical content and clinical features.
The customer record stores counters for no-shows recorded by the business and cancellations by the customer. They are informational and block nobody.
We do not ask for age or birth year. In the Loyalty programme, the customer may optionally provide the day and month of their birthday; these are stored with their origin and change history to apply the programme’s rules. Communication preferences and their evidence are also retained. Collecting these data does not by itself activate sending.
We recognise that the name of a service or of a professional can, on its own, suggest something about health. That is why calendar events and messages are designed not to expose more than necessary, and why clinical data is forbidden throughout the product.
5. Contact verification and the one-time code
Not live yet
Before a booking made on the public page is accepted, the contact detail has to be proven. We send a six-digit code by email or SMS and it has to be returned.
The code is never stored. It is derived, at the moment of comparison, from a random value that changes on every send. Our database does not hold it, in clear or encrypted, and neither does the record of the sending job.
The challenge does store the destination — the email address or the number — in clear, because something has to know where to send the message. That record is deleted automatically shortly after it stops being valid; see the retention section.
A code is valid for 10 minutes, allows 5 attempts, has a 60-second interval between sends and a maximum of 5 sends per hour to the same destination at each business. Further limits apply per request origin and per business.
Once the contact detail is proven, the device receives a cookie that avoids repeating the code for 60 days at that business. It is explained in the cookies section.
Sending the message depends on the channels described in the messages section, which are not yet live as at this version. The generation, the verification and the limits described above already work exactly as described here.
6. Data about people who visit the public page
Visiting a business's public page requires no account and no contact details.
To stop abuse — bulk code sending, attempts to guess codes, automated bookings — we keep counters per request origin, per business and, when a booking is created, per contact detail used. None of those values is stored as you wrote it: each is turned into an irreversible value with a secret key, and what stays in the database is that value plus a timestamp. The IP address is never stored, and on IPv6 the counter is per /64 block rather than per address, because a home connection is given a whole /64.
We use Cloudflare Turnstile on code sending and on booking creation, to tell a person from a script. It is an anti-bot challenge with no puzzles and no cross-site tracking.
We use no advertising, no marketing cookies and no audience analytics tools. There is no profiling and no automated decision-making with legal effects on you.
7. Messages we send
Not live yet
The platform sends transactional messages about a booking: confirmation (with a calendar file and a lookup link), change, cancellation, refund confirmation and a reminder before the appointment.
When notifications are activated, email and SMS will be sent through Arpoone, a platform operated in Portugal by SEND IT — Software e Serviços para Telecomunicações, S.A.
Messages go out in the language of the booking. The SMS always includes the short lookup and cancellation link.
We send no marketing. There is no newsletter subscription in this product.
This section describes behaviour that is already designed and not yet live as of this version.
8. What we do not store and what we do not do
The most useful guarantees in a policy are the negative ones, and these correspond to concrete construction decisions in the system.
Verification codes are not stored: they are derived at the moment of comparison.
Contact details are not used as a lookup key in clear. The index that stops the same person being duplicated stores an irreversible value derived from the contact, not the contact.
The audit records — who published, who cancelled, who refunded — store identifiers, amounts and the actor. They never store names, emails or phone numbers.
Technical logs contain no email, phone number, token, code or booking content. The error reporting service runs with personal-data collection switched off in every runtime, and reports generated on the server are additionally stripped of cookies, headers, request body, IP address and email before being sent. Session replay is off.
We do not store card details or other payment instrument data.
We do not use identifiable data for marketing, for benchmarking between businesses, or to train artificial intelligence models.
We do not sell personal data.
10. The legal basis for each activity
| Processing | Legal basis | Controller |
|---|---|---|
| Creating and managing a booking | Performance of the contract between consumer and business (Art. 6(1)(b)) | The business; us as processor |
| Verifying a contact detail with a one-time code | Performance of the contract and legitimate interest in preventing bookings in other people's names (Art. 6(1)(b) and (f)) | The business; us as processor |
| User account and subscription | Performance of the contract (Art. 6(1)(b)) | Tá Marcado |
| Subscription invoicing and accounting | Legal obligation (Art. 6(1)(c)) | Tá Marcado |
| Security, abuse limiting, anti-bot and technical logs | Legitimate interest in keeping the service available and secure (Art. 6(1)(f)) | Tá Marcado |
| Google Calendar synchronisation | Consent of the business or professional, withdrawable at any time (Art. 6(1)(a)) | The business; us as processor |
11. How long we keep things
The table separates what is already implemented, with the exact period the system applies, from what is still a proposal to be validated. The separation is deliberate: we would rather say what is not yet decided than state a period that does not match what the system does.
| Data | Period | Status |
|---|---|---|
| Verification challenge (destination; the code is never stored) | Deleted automatically 1 hour after the last deadline of the challenge expires — in practice a little over an hour after sending | Implemented |
| Abuse-limiting counters | Deleted automatically 1 hour after the counter drains | Implemented |
| Verified-contact device record | Valid for 60 days, deleted 7 days later | Implemented |
| Booking lookup link | Valid for 365 days, deleted 30 days later | Implemented |
| Error reports | Proposal: 30 days | Proposal to validate |
| Database backups | Daily backup kept for 7 days and point-in-time recovery over the last 7 days | Implemented |
| Panel user account | Proposal: for as long as the account belongs to a business, and deleted at the request of the data subject | Proposal to validate |
| Bookings and their snapshot | Proposed: 3 years after the appointment date | Proposal to validate |
| Customer record (name, contacts, counters) | Proposed: while the business is active and up to 3 years after the last booking | Proposal to validate |
| Internal notes written by the business | Proposed: deleted with the customer record | Proposal to validate |
| Audit records (no contact details) | Proposed: 2 years | Proposal to validate |
| Payment and refund records (no card data) | Proposed: 10 years, on tax and accounting grounds | Proposal to validate |
| Billing profile and subscription history | Proposed: 10 years, on tax and accounting grounds | Proposal to validate |
| Record of events received from Stripe | Proposed: 12 months | Proposal to validate |
| Export files, reports and access/portability copies | Available for 1 hour after becoming ready, within current authorisation; resumable technical cleanup | Implemented; not retention of the source data |
| Birthday day and month, Loyalty, Reviews, preferences and personal analytics derivatives | Period, purpose, context and exceptions to be decided by class in the matrix; old proposals are not automatically inherited | Proposal to validate |
The periods marked as proposals are not settled and must be validated by a lawyer before public launch. They are here as a concrete proposal for that review, not as a commitment in force.
12. Who we share with
We neither sell nor rent personal data. We share only with the providers needed to deliver the service, and only what is needed.
| Provider | What for | Where |
|---|---|---|
| Google (Firebase Firestore) | Application database | European multi-region |
| Google (Firebase Authentication) | Accounts and passwords of people who run a business | United States |
| Vercel | Application hosting and execution | Frankfurt; company based in the United States |
| Stripe | Subscription charging and booking payments | Ireland and United States |
| Cloudflare | Turnstile, the anti-bot challenge | Global network |
| Sentry | Error reports, configured without personal data | Account in the European Union region |
| Arpoone (SEND IT, S.A.) | Transactional email and SMS delivery | European Economic Area |
| Google (Calendar and Meet) | Optional synchronisation of a professional's diary | United States |
| Kapta and Moloni | Issuing the certified invoice for the platform subscription | Portugal |
The Google Calendar and message-delivery rows concern features that are not live yet. Kapta and Moloni handle only the invoicing of our own subscription, where we are the controller, and never booking data; that is why they are not in the annex to the Data Processing Agreement.
13. Transfers outside the European Economic Area
The database sits in a European multi-region and the application runs in Frankfurt. There are, even so, transfers outside the EEA that we state expressly.
Firebase Authentication, which holds the accounts and passwords of people who run a business, is operated by Google in the United States. That is a property of the service, not a configuration choice of ours.
Some of the remaining providers are United States companies or have operations there, even where the data itself is hosted in Europe.
These providers state that they rely on the European Commission's Standard Contractual Clauses and, where applicable, the EU-U.S. Data Privacy Framework. The specific mechanisms, provider by provider, must be confirmed and cited in the legal review of this document.
14. Your rights and how to exercise them
You have the right to access your data, correct it, erase it, restrict or object to processing, and to portability. Where processing rests on consent, you may withdraw it at any time, without affecting what was done before.
You may write to geral@tamarcado.pt. The platform also has a business-specific journey for access, portability, correction and erasure requests, whose availability depends on activation of verification-code delivery. Contact by email remains available.
Before responding we must confirm identity by a means proportionate to the request. The platform journey uses a code sent to the email associated with the data subject at that business: it lasts 10 minutes, allows 5 attempts and creates a 30-minute session. It gives no access to other people’s or businesses’ data.
Requests about booking data are handled separately for each business and depend on instruction from its owner, as controller. The data subject’s copy includes only their covered data, including relevant Loyalty, Reviews and analytics data; it does not include the global export, third-party data, unrestricted internal notes or usable credentials.
Erasure and anonymisation require a verified instruction and an approved retention policy for the covered classes; periods marked as proposals do not authorise automatic erasure. Corrections propagate to covered copies and revoke dependent access. Erasing the authentication account is a separate journey requiring recent authentication and no outstanding access or obligations; closing a business does not delete an account serving other businesses.
Access and portability copies are available for 1 hour after they become ready. The session and authorisation are checked again on every download; obtaining a link does not extend that hour. The end of commercial access does not remove the journeys necessary to exercise rights.
If you consider the processing unlawful, you may complain to the Portuguese data protection authority, the Comissão Nacional de Proteção de Dados (www.cnpd.pt).
15. Security
The direct database access rules deny everything: no browser reads or writes data directly. All access goes through the server, which checks the session, membership of the business and the role before any operation.
The browser never sets prices, business, payment account, permissions or the final state of a booking.
Public requests that write data pass through abuse limiting before they touch the database, and code sending and booking creation additionally pass through an anti-bot challenge.
Events received from Stripe are verified by cryptographic signature before being accepted.
Secrets are separated by environment and rotated when needed.
Multifactor authentication for administration has its own implementation, but its activation and operational enrolment still need to be demonstrated. This draft does not present it as an already active protection.
No technical measure makes a system impregnable. If a personal data breach occurs that poses a high risk, we comply with the notification duties set out in the GDPR.
16. Google Calendar, Google Meet and Limited Use
Not live yet
The Google Calendar and Google Meet integration is still being prepared. Once available, connecting one calendar per professional will be optional, off by default and revocable. These terms describe the planned processing, not a feature that is already live.
Authorization will allow listing calendars to choose one, checking availability and reading, creating, updating and cancelling booking events in the selected calendar. Gmail, Drive, contacts and Meet recordings will not be requested. Meet will be created through the Calendar event where applicable.
The refresh token, which renews access without asking for authorization on each use, will be stored encrypted with Google Cloud KMS. Keys will be separate between environments and encryption will be bound to the business, professional and user who authorized the connection. Temporary access tokens will not be included in logs.
For external events, only the opaque identifier, start, end and status needed to determine unavailability will be retained. Titles, descriptions and attendees will neither be requested nor stored for this purpose. These data will be used exclusively for availability and booking synchronization.
Events created by the platform will be titled “Reserva”, with the time, an opaque internal reference and an authenticated panel link. They will not include the consumer’s name, email, phone number, service or notes, and the consumer will not be added as an attendee.
We will not sell Google data or use it for advertising, credit assessment or training general-purpose artificial intelligence models. Transfers will be limited to the requested feature, security, legal obligations or other cases expressly permitted by Google policy. There will be no human reading of calendars in normal operation; any exception must meet that policy’s specific requirements, including explicit consent for the data concerned where required.
On disconnection, the implemented flow blocks new synchronisation and records authorisation revocation and the stopping of change channels. Cleanup is resumable: the encrypted token needed for revocation is removed only after confirmation, and availability data derived from the connection is cleaned up. Authorisation can also be withdrawn in the Google Account’s third-party connections. Backup copies expire according to their own lifecycle; a restore must replay deletions and reconcile corrections before reopening access. This does not promise immediate removal of every copy or demonstrate activation or live execution of the integration.
Limited Use commitment: Tá Marcado's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
17. Children
The platform is for businesses and for people booking a service for themselves. We do not collect age or date of birth and we do not direct the service at children.
Where a booking is made for a minor, it is made by whoever is responsible for them, and it is the business — as controller — that collects it on those terms.
18. Changes to this policy
This policy carries a version and a date, shown at the top. When we change something that affects you, we update the version and, for businesses with an active subscription, tell them through the account's contact channels.
19. Contact
GD Projects, Lda., Rua Dom Diniz, n.º 45, Burinhosa, Pataias, 2445-042 Pataias, freguesia de Pataias e Martingança, concelho de Alcobaça, distrito de Leiria, VAT 519433858, Conservatória do Registo Comercial de Coimbra, NIPC 519433858 — Insc. 1, AP. 11/20260515.
For any question about this policy or about your data: geral@tamarcado.pt.
No Data Protection Officer has been appointed, as one is not required given the nature and scale of this processing.
Supervisory authority: Comissão Nacional de Proteção de Dados, www.cnpd.pt.