Privacy

Who holds what, and in which role

Pumasi Booking is scheduling software. Two different relationships run through it, and they carry different duties.

• For the people who own booking pages (an account holder, and the company they work for) we are the controller of the account itself: the address you sign in with, your name, your settings.
• For the people who book a meeting — everyone who fills in a booking page — we are a processor acting for the account holder. They decide to collect it; we hold it on their behalf and act on their instructions. If you booked a meeting and want your details removed, the fastest route is the link in your confirmation email, described below; you may also contact us and we will act. This matters most where an organiser has added their own questions to their page: we did not choose those questions and do not control what they ask. See *What is collected*.

Operator: ATX APPLE LLC, a Texas limited liability company, United States. Contact us about anything on this page at admin@pumasi.ai — that address reaches the people who run the service, and it is the fastest route.

What is collected

Nothing about *you* is collected that the meeting does not require. This is the complete list of what the service stores about a person. The software's own self-reporting is described at the end of this section; this deployment sends none of it today.

If you book a meeting, the booking page asks for and stores: - your name and email address, because the person you are meeting needs to know who is coming and how to reach you; - the time you chose, its end, and the timezone your browser reported, so the meeting appears correctly for both of you; - a single-use management link which is emailed to you and to nobody else. It is the credential that lets you change or cancel the booking without an account. - your answers to any questions the organiser added to their own page, along with the question exactly as it was worded when you answered it.

There is no other field on the form, and no hidden one.

The questions are the organiser's, and so are the answers. Anyone running a booking page may add their own questions to it, and we do not choose, review, or limit what they ask. For those answers the organiser is the controller — they decide what to ask and why — and we hold the answers on their behalf, as their processor, exactly as we do the rest of the booking. If you want to know why a question was asked, or you want those answers removed, the organiser is the right person to ask; you can also delete them yourself with the link in your confirmation email, and you can also contact us and we will act.

Two details that follow from that, and that we would rather state than have you discover: the wording of a question is saved onto your answer, so an organiser who later rewrites the question cannot change the record of what you were actually asked; and if an organiser deletes a question, answers already given are not deleted with it, because they are the record of an exchange that happened. Deleting your booking details deletes the answers too — that path reaches them.

The person you are meeting may afterwards add, about that booking: - a private note (visible only to them), and a no-show marker. - Your name and address also become a contact in their account, so they can recognise you next time. They can exclude addresses or whole domains from this entirely, and delete any contact.

If you vote in a meeting poll, we store your name, your email address, and which proposed times you accepted, until the poll is deleted.

If you answer a routing form — the one-question form that sends you to the right booking page — your answer is not stored at all. It selects a destination and is gone.

What the software reports about itself. The self-reporting mechanism the governing document (REPORTING.md) describes is now built into this software. Two facts, stated separately because they differ:

This deployment — the one serving this page — still sends nothing. The mechanism is not wired into it; no such data leaves it today. When that changes, this paragraph changes first.

Self-hosted deployments send an operating report by default: what platform the software runs on, the shape of its configuration (which switches are on — never their values), uptime, and an error count. It carries no name, no email address, no meeting time, no note contents, nothing a booker or organiser typed, and no counts of bookings or accounts. It is not published. It is kept for twelve months and then deleted, and deleted earlier on request to admin@pumasi.ai — deletion reaches backups within 30 days. The operator turns it off in one step (PUMASI_REPORTING=false) and the software behaves identically afterwards. The receiving service is not yet live; until it is, these reports go nowhere and nothing is retained anywhere. There is also a conformance report — did the test suite pass on this platform — that an operator can *choose* to publish, signed with their own identity; it is never sent automatically. The basis for all of it is our legitimate interest in operating and improving software we give away.

If you hold an account, we store your email address, display name, timezone, your public link name, an optional welcome message and accent colour, your availability and event settings, your team memberships, and a record of sign-ins and administrative changes to your account (an audit trail). Sessions are cookies; sign-in is by emailed link or by your Google or Microsoft identity — we never hold a password, because the service has none. API keys and SCIM tokens are stored only as irreversible digests: we cannot read them back to you, only check one you present.

If you connect a calendar (optional), we store the account's email address and the access credentials, encrypted at rest with AES-256-GCM under a key held in deployment secrets and not in the database. By default the permission we request is free/busy only: we receive the start and end of the periods you are busy, and not the titles, attendees, locations or contents of your events. Writing your bookings into your calendar is a separate permission you grant deliberately, and only then.

Technical data. To stop abuse we record, for at most two hours, a short-lived counter derived from the requesting IP address. It is deleted automatically after that. Our hosting provider processes connection data (including IP addresses) to deliver the request, as any host must.

We run no analytics, no advertising, no tracking pixels, and no third-party scripts. The only cookies are two strictly necessary ones: your session, and a marker recording which organisation's workspace to route you to. There is no consent banner because there is nothing to consent to.

On what basis

• For account holders: performing the contract you have with us, and our legitimate interest in operating and securing the service (the audit trail, the abuse counters).
• For bookers and poll voters: the account holder's legitimate interest in arranging a meeting you asked to arrange, with us processing on their instructions as their processor. In practice you provide the data yourself, to meet someone you chose to meet, and you can remove it yourself at any time.
• We do not rely on consent for cookies, because we set none that would require it, and we do not sell, rent, or share personal data for anyone else's marketing. There is no profiling and no automated decision-making with legal effects.

Where it lives, and who else sees it

The service runs on Cloudflare, which provides the compute and the database; each customer organisation's data sits in its own isolated database. Confirmation and reminder email is sent through Google (Gmail API). If you connect a calendar, the relevant parts of a booking reach Google Calendar or Microsoft 365 because that is what connecting a calendar means.

Every third party that can see personal data is named, with what they see and why, in our subprocessor register. That register is enforced by the software, not merely written down: the service will not send mail through a provider that is not listed. Bookings still work; the confirmation waits.

The service is operated from the United States and your data is processed there. If you are outside the United States, using it means your details are transferred there. We say that plainly rather than name a transfer mechanism we have not put in place.

How long it is kept, and how to delete it

• A booking is kept until it is deleted. Its management link works until the meeting ends plus seven days.
• Your details as a booker: use the link in your confirmation email and tick the confirmation box. This cancels the booking and deletes your name, address, timezone, the private note about you, the contact entry created from your booking, and any not-yet-sent email that contained your details. What remains is an anonymous record that a slot was booked and cancelled.
• An account: deleting it removes the account, its booking pages, every booking on them including the bookers' details, contacts, calendar credentials, availability, team memberships and sharing links — in a single transaction, and verified by absence rather than by a flag.
• Poll votes are deleted with the poll.
• Abuse counters are deleted automatically after two hours.
• The audit trail of account sign-ins and administrative changes is retained while the account exists and is deleted with it.

What deletion cannot reach, stated plainly: an email already sent is in the recipient's mailbox and in the sending provider's logs, and we cannot recall it. An event already written into someone's calendar is removed when the booking is cancelled, but copies may persist in that provider's own history. This service currently operates no backups of its own; if that changes, this section will say how long they are kept and the change will be visible in the repository's history.

Your rights

You may ask us for a copy of what we hold about you, to correct it, to delete it, to restrict or object to processing, or to receive it in a portable form. Write to admin@pumasi.ai. We will respond within one month. If you booked a meeting through someone's page, we may need to refer the request to them as the controller, and we will tell you when we do.

If you are in the UK or the EU, you may complain to your own national data-protection authority. We would rather you wrote to us first, but that right does not depend on us.

Security

Traffic is encrypted in transit. Calendar credentials are encrypted at rest. API keys and SCIM tokens are stored as digests and shown once. There are no passwords to steal because the service has none. Each customer organisation is isolated in its own database rather than sharing one. Access to production is limited to the steward.

We are a small operation and we do not claim a certification we do not hold. What we claim is that the design decisions above are real and checkable in the published source.

Changes

Material changes will be announced to account holders before they take effect. Every version of this document is in public version control, so what changed and when is inspectable rather than asserted.