Privacy Policy. Written from what the code does.

• Customers are the people who sign up for a Setupp workspace, add hosts and connect a calendar. For their account and calendar data, Setupp decides how the data is handled and is responsible for it. In GDPR language, we are the controller.
• Bookers are the people who fill in an intake form and book a meeting with a customer. For that data the customer is in charge and Setupp acts on their instructions. In GDPR language, the customer is the controller and Setupp is the processor. If you are a booker and want something removed, the fastest route is the organisation whose page you booked on. Email us anyway if that goes nowhere.

• Your email address, and the authentication record created for it when you sign in.
• Your workspace: its name, its URL slug, its plan, and any brand settings you choose (an accent colour, a font and a logo URL used to style your booking page).
• Who is in the workspace and what role they hold: owner, admin or member.
• Each host you add: name, email address, job title, avatar URL, time zone, and whether they are currently active.
• Your configuration: event types and their durations, buffers and notice periods; availability schedules and date overrides; the questions on your intake forms; your qualification rules; and your scoring profiles, including the ideal-customer paragraph and criteria you write.

• Free/busy windows for each connected calendar: the start and end times of blocks when a host is busy. No titles, no guests, no descriptions, no locations, no attachments. These windows are used to compute availability inside the request that asked for it and are not written to the database.
• The events Setupp itself creates: we store the Google event id and the Meet link on the booking, so the event can be updated or cancelled later.
• The email address of the connected Google account, used to label the connection in your dashboard.
• The OAuth access and refresh tokens that authorise those two things, plus their expiry and the scopes granted.

• Their name and email address.
• Their company, when your form asks for it.
• Every answer to your intake form, stored exactly as submitted.
• The time they chose and the time zone they chose it in.
• Whether the submission tripped a rule you marked as a flag rather than a block.
• The state of the booking (confirmed, cancelled, rescheduled, completed or no-show), and a random token generated so a cancellation link can identify the booking without exposing anything else.

If a booker is declined by a blocking rule, nothing about the person is written down. Their name, their email, their company and every answer they gave are checked in memory, the request is refused, and they are discarded. Not hashed, not kept in any form, because a hashed email is still an identifier.

What is recorded is the decision: which event type, which of the customer’s own rules said no, and when. That is what lets an operator see “thirty-two people were turned away by the budget question” and reconsider the question. It cannot be traced to anybody, because there is nothing in the row to trace. See declined_attempts in the exception at the end of this section.

• The Setupp Score: a number from 0.0 to 10.0, its band, a short paragraph of written reasoning addressed to the host, and one signal per scoring criterion with a value and a one-line note. We also store which engine produced it, so you always know whether a model or the deterministic fallback wrote it.
• Email delivery records. For each message Setupp tries to send: the recipient address, which template it was, the provider’s message id, whether it succeeded, any error, and the time.

• No payment card details, ever. Card data goes to the payment processor and never reaches Setupp. There is no column for it and no code that could read one.
• No advertising or tracking pixels, no device fingerprinting, no session recording, and no advertising cookies. There is one analytics script: Google Analytics, described in its own section below. It is set to deny every advertising and identification purpose before it loads.
• IP addresses are read from request headers to rate-limit the public booking endpoints. They are held in the running server process for the length of the rate-limit window (a minute) and are never written to the database.
• No special categories of personal data, unless a customer's own intake form asks for them. If a form asks, that is the customer's decision and the customer's responsibility.

Two tables are named here rather than folded into one of the four, because neither is about a person. Both are listed in full.

• billing_events: one row each time a workspace’s plan changes. It holds the workspace id, the plan it moved to, the reason, the name of the payment processor, that processor’s own reference for the event, and the time. No amount, no card, no billing address and no customer name.
• declined_attempts: one row each time a qualification rule turns somebody away. It holds the workspace id, the event type id, the ids and question keys of the rules that blocked, and the time. No name, no email address, no company, no answers, and no hash or fingerprint of any of them. There is no column a person could be identified from, which is a stronger promise than a policy of not filling one in.

The first exists so a plan change can be proved and reversed; a webhook that silently upgraded a workspace with no record of who sent it would be worse for you than that row is. The second exists so a customer can see which of their own questions turns people away, and it is designed so that answering that question never requires knowing who those people were.

Availability comes from a single call: freebusy.query. Google answers it with a list of busy start and end times. It does not return event titles, guest lists, descriptions, locations or attachments, and Setupp does not ask for them anywhere else in the product. Setupp never opens, lists or reads the contents of an event it did not create.

Free/busy is read for exactly one purpose: computing the times when every required host on an event type is free at once. The result renders the calendar on your booking page and is checked again at the moment someone books, so a slot that has since been taken cannot be double-booked. Setupp does not keep a copy of your calendar.

One event per booking, on the connected calendar. Every host is a full attendee on it, the booker is on it too, and Google sends the invitations, the updates and the cancellations itself.

Each event Setupp creates carries a private marker: extendedProperties.private.setuppBookingId. Any later update or cancellation is matched on the event id Setupp stored for that booking. Setupp does not read, modify or delete any other event on your calendar. There is no code path in the product that can.

You can withdraw Setupp’s access to your Google account at any time at myaccount.google.com/permissions. That stops Setupp reading free/busy or writing events immediately, and makes the stored tokens useless. Events already on your calendar stay where they are, because they are yours.

When a booking is confirmed on an event type that has a scoring profile, Setupp sends one request to the Anthropic API. It contains:

• The workspace's scoring criteria and the ideal-customer paragraph the customer wrote.
• The booker's answers to the intake form, each with the label of the question it answers. Fields the customer marked private on the form are stripped out before the prompt is built and never reach the model.
• The booker's name, their company if the form captured one, the title of the event type and how long it is.
• How many qualification flags the submission tripped, as a number.

That is the whole payload. Setupp does not send the booker’s email address, any calendar or free/busy data, any OAuth token, or anything about any other booking. If your own intake form asks a question whose answer contains personal information, that answer is part of the payload. You decide what your form asks.

These requests go to Anthropic’s commercial API, under terms in which inputs and outputs are not used to train Anthropic’s models. Setupp runs no training or fine-tuning of its own. If the Anthropic integration is unavailable or the call fails, Setupp falls back to a deterministic rules engine that runs entirely on our own server and sends nothing anywhere. The score card tells you which engine produced the number.

The database is hosted by Supabase in Amazon Web Services’ ap-south-1 region, in Mumbai, India. Resend, Anthropic and Google process data on their own infrastructure, which for those three includes the United States. If you or your bookers are in the UK or the EEA, that is a transfer outside your region.

We use each provider under the data processing terms they publish. We have not negotiated bespoke agreements with any of them, and we are not going to pretend otherwise.

The public marketing pages run Google Analytics. It loads with Google Consent Mode set to deny analytics storage, advertising storage, ad user data and ad personalisation. That default is registered before the Google library loads, not after, which is the difference between a default that applies and one that arrives too late to matter.

• If you decline, or ignore the prompt: no cookie is set. Google receives a cookieless ping (a page address, a referrer, a coarse location from a truncated IP) with nothing that links this visit to any other. We learn that a page was read. We do not learn that you read it.
• If you accept: Google sets its _ga cookie so repeat visits count as one person rather than several. Advertising storage and personalisation stay denied either way. That is not a preference we offer, because we do not advertise.

Analytics runs on the marketing pages only. It is absent from every booking page, from the embedded widget and from every dashboard, so nothing a booker types, and nothing a customer configures, is ever measured by it. Your choice is stored in your own browser under setupp.consent.v1, is never sent to us, and clearing your site data resets it.

Our database provider keeps its own backups on its own schedule. A deleted row can persist in those backups until they roll over. We have no mechanism to reach into a provider backup and remove a single row, and we are not going to imply we do.

If you booked a meeting through a Setupp page and want your data removed, ask the organisation you booked with first. It is their workspace and their data to delete. You can also email support@usesetupp.com and we will pass the request on and help them action it.

• Customer account and workspace data: to perform the contract we have with you.
• Google calendar data: your consent, given on Google's consent screen, which you can withdraw at any time.
• Rate limiting and abuse prevention: our legitimate interest in keeping the service available.
• Booker data: the customer whose booking page it was decides the basis for it. Setupp acts on their instructions.

Two things in Setupp are automated and worth naming plainly. Qualification rules can decline a booking with no human involved; those rules are written by the customer and are the customer’s responsibility. The Setupp Score is generated after a booking is already confirmed, is shown only to the host, is never used to decline anyone, and is never shown to the booker.