Privacy policy

This page describes what data OpenSignup collects and how it is used. It is written in plain English and reflects what the code actually does — the source is open and you can verify any claim here against the schema at github.com/richshaw/OpenSignup.

The OpenSignup project is an open-source coordination tool released under AGPL-3.0. This page applies to this instance — the deployment you are currently using. The data controller for this instance is the operator of this instance.

What we collect from organizers

Organizers (people who create signups) sign in without a password — either via a magic link sent to their email or, where the operator has enabled it, an optional third-party sign-in such as Google. We store:

• Email address (used to send magic-link sign-in emails).
• Optional display name and organization name.
• The signups, slots, and settings you create.
• An append-only activity log of organizer actions (sign-ins, creating and editing signups, sending magic links, copying a signup’s link, or from the share panel sending it by your phone’s share menu, choosing Email it, or showing or saving the QR code, a publish or an AI draft that didn’t go through, and whether AI drafting asked you questions and how you answered them, in counts only, never what you or the AI wrote), which of your own pages you open and whether on a phone or a computer (never the browser’s full identifying string), participant commitments on your signups, and reminder dispatches. For a copy or a share it records only which button it was and the signup’s status: never the message, and nothing about who the link went to. This exists so an organizer can audit what happened in their own workspace, so the operator can investigate abuse, and so the operator can count, in aggregate, where organizers get stuck between starting a signup and sharing it. The same log records anonymous view telemetry on the marketing pages and on your public signup pages (see “Logs and rate-limiting” below).
• After a sign-in email is sent, the sign-in link's token (stored as a hash, next to your email address), kept until the link expires (an hour by default, or as long as the operator sets it). For up to 15 minutes, the six-digit code printed in the email (stored as a keyed hash) with the encrypted sign-in link it stands for, so you can finish signing in from the window you started in. Both are single use. A used or expired one cannot be redeemed, and an hourly cleanup deletes any that are left.
• If you connect an app or AI assistant to your account, a record of that approval and the tokens that keep it working. See “Connected apps and AI assistants” below.

No password is ever stored — sign-in is passwordless.

What we collect from participants

Participants (people signing up for a slot) never create an account. When you commit to a slot we store only what is needed to honour your commitment:

• Display name.
• Email address, if you give one. The organizer decides whether a signup requires it. We use it to send you a confirmation with your link to change or cancel, and, if the organizer has reminders on, reminders and an email when your slot moves to a new date or time. If you leave it blank where that is allowed, we send you no emails. Your link is then shown on screen after you sign up, and only that browser remembers it: for 60 days, or until a week after your slot if that is later.
• Your slot selection, quantity, and any optional notes.
• Whether you have opted out of reminder emails for that signup, and when.

A browser cookie keeps your link to change or cancel, so you can come back to your own commitment from the same browser. See the cookies page for details.

Logs and rate-limiting

To prevent abuse, the server records request IP addresses in short-lived rate-limit records (e.g. to throttle magic-link sends). These rows are scoped to individual buckets and are not joined to your account or commitment for analytics. Server-side application logs are standard request/error logs and do not include cookies, tokens, magic-link URLs, or email addresses; sign-in log lines name only the part of the address after the @.

For each view of a public signup page, the server writes a single activity entry containing a user-agent class (browser, bot, or unknown), the host of the referring page (not the full referer URL), the signup's status, and whether the viewer is a returning participant on that signup. We do not record your IP address on this entry. Bot traffic and requests carrying a Do Not Track or Global Privacy Control signal are skipped. The same applies when you follow an “edit your commitment” link, when you load the marketing home page, and when you click the “Start a signup” button on it (where we record only the user-agent class and the referring host). It also applies when you load one of our other marketing pages or click a button on one, where we record which page it was, the user-agent class and, for a page load, the referring host. If a button on one of those pages takes a signed-in organizer to start a new signup, the entry for that step in the organizer's activity log notes which page the button was on.

Email delivery

OpenSignup sends four kinds of email: organizer magic-link sign-in emails, a confirmation to a participant when they commit to a slot, a reminder before a dated slot, and an email when the organizer moves a participant's slot to a new date or time. A participant gets these only if they gave an email address. Moving to a different slot gives your spot a new private link, and sends a fresh confirmation with it. The old link then leads to the new one. Each of these participant emails contains a private link that lets you change or cancel that commitment without signing in, so treat them as you would a password and don't forward them. Reminders go out the day before the slot, and a moved-slot email about 10 minutes after the organizer's last change to its date or time; organizers can turn both off for a signup entirely, with the reminders setting. Every reminder and moved-slot email carries a link that stops both for that signup; we record only the time you opted out, and it does not affect any other signup or your slot itself. Delivery uses whichever transport the operator has configured (SMTP, a transactional provider, or local console output in development). No marketing email is ever sent.

Connected apps and AI assistants

An organizer can connect a third-party app, typically an AI assistant such as the Claude app, Claude Code, or ChatGPT, to their OpenSignup account. Nothing is connected unless the organizer approves it on a consent screen that names the domain the app identified itself from (or, for an app the operator of this instance registered in advance, the name the operator gave it) and lists exactly what it will be able to do. Participants are never asked to sign in and cannot connect anything.

A connected app acts as the organizer who approved it, across every workspace that organizer belongs to, with the same role and never more access than the organizer has themselves. Permissions are approved individually: seeing your signups and their slots, and creating, editing, publishing and deleting signups. Participant names and email addresses sit behind a separate permission an app has to ask for explicitly; the consent screen flags it in amber and says plainly that participants gave those details to you, not to the app. An app that was not granted that permission cannot read participant details at all.

For each connected app we store the approval (which organizer, which app, which permissions, when it was approved, when it was last used, and when it expires), the app's identifier and the name it reports about itself, the refresh tokens that keep the connection alive, and, for the minute it takes to set a connection up, the single-use code that establishes it. Access tokens themselves are not stored. The activity log records that a connection was approved, declined, or disconnected, together with the app's domain (or its configured identifier, for a pre-registered app), and, for every change a connected app makes on your behalf, which app made it. It never records a token or an email address.

You can see and end every connection from Connected apps in your account settings. Disconnecting deletes the approval and every refresh token under it at once, so the app can get no new access; an access token it already holds keeps working until it expires, which is at most 15 minutes. No approval survives longer than 90 days without you approving the app again.

Whatever a connected assistant reads under the permissions you approved is then processed by that assistant's vendor under their own terms and privacy policy, not ours. Apart from AI drafting, described under “Third parties” below, OpenSignup sends nothing to an AI vendor itself: only an app you connected, acting on your instructions, can pull data out.

Third parties

OpenSignup is designed to have no required external dependencies beyond a Postgres database. Optional integrations (email provider, error reporting, product analytics, AI draft generation, and third-party sign-in) are off by default and only enabled if the operator has configured them via environment variables. Where this instance has enabled any such integration, the operator will list it on request. Separately from anything the operator configures, an organizer can connect an app or AI assistant to their own account. See “Connected apps and AI assistants” above.

If the operator has turned on AI drafting, what an organizer types into it to describe their signup, along with any answers they give to the questions it asks, is sent to the AI provider the operator configured, which turns it into a draft. It goes as typed, so leave out anything you wouldn't want the provider to see; nothing else about you, your signups or the people on them goes with it. The provider handles it under its own terms. To keep a description away from the provider, skip AI drafting and fill the signup in by hand.

If third-party sign-in (for example, Google) is enabled and you choose it, you authenticate on the provider's own site and they return your email, name, avatar, and a unique account identifier. We store the link between that provider account and your organizer record — along with the standard sign-in tokens the provider issues — so we can recognise you on future sign-ins. We do not use those tokens to access anything on the provider beyond the basic profile needed to sign you in.

Your rights

You can request a copy of the data we hold about you, or ask us to delete it, by emailing hello@opensignup.org. Today this is a manual process — self-service export and deletion endpoints are on the roadmap. Organizers can already delete a signup from its settings. That takes the signup and everyone's commitments to it off the site at once: its page and everyone's edit links stop working, lists and exports stop showing them, and nobody can sign up to it. The records themselves stay in our database until someone asks us to erase them, as above.

Self-hosting note

If you are reading this on a self-hosted copy of OpenSignup, the operator of that instance — not the OpenSignup project — is responsible for how your data is handled. The OpenSignup project publishes source code only; it does not operate or have access to data on other people's deployments.

Contact

Questions about this policy or about data we hold: hello@opensignup.org.