Privacy

Who holds what, and in which role

Nolizi Calendar 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@nolizi.com — 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; - your chosen meeting location, including the host’s location details, so everyone knows where to meet; - 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 an organiser imports contacts, we store the names and email addresses they provide. Importing does not send an invitation or create a booking. The organiser can delete those contacts and exclude addresses from future collection.

If you reserve a group-session seat, we store your name, email, timezone and reservation status. The host can schedule an attendee reminder one hour or one day before the session; cancellation and deletion remove pending reminders. The host sees the attendee list; the public session page does not. Your private confirmation link allows cancellation, moving to an available session with the same host, and deletion of your attendee details. It expires seven days after the session ends. Deletion also removes pending attendee messages; already sent messages and recipients' copies cannot be recalled.

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 questions that send you to the right booking page — your answers are not stored at all. They select 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@nolizi.com — 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.

Google API data and Limited Use. Nolizi Calendar’s use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements. We use connected Google Calendar data to check availability and, when you grant write permission, create and maintain your booked meetings and Google Meet links. We do not use this data to train general-purpose AI or machine-learning models, or for advertising.

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 advertising, tracking pixels or third-party scripts. When configured, PostHog receives optional product-usage events from our server only after you enable usage analytics in the signed-in application. These events contain canonical screen names, menu selections, saved setup progress, a pseudonymous account identifier, a short-lived session identifier, and the application release. They do not contain form values, page contents, email addresses, document contents, or raw URLs. Session replay is disabled. Staff and test accounts are excluded. You can disable collection using the same control; we also honor browser Do Not Track and Global Privacy Control signals for this optional collection. The preference cookie lasts 30 days and the usage-session cookie expires after 30 minutes without activity. Disabling collection stops future events; contact us to request deletion of earlier usage records. PostHog is listed below in the subprocessor register.

Session and workspace cookies keep you signed in and route you to your workspace. If you follow the optional “Create my booking page” link after a booking, a first-party source cookie lasts up to 30 days. For a new account created through that path, we record when the account was created, when it first created a booking page, and when it first received a booking. These milestones are deleted with the account. They do not include or link to the original guest booking. You can create an account directly at /signup without this source marker. Booking never requires an account or this invitation.

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 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@nolizi.com. 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.