Privacy policy

1. Who we are

HeadsUp RSVP is a business name of HeadsUp RSVP Pty Ltd (ABN 17 701 899 774). Our ACN is 701 899 774 and we’re an Australian company. We run the invite service at headsup.rsvp, the HeadsUp iPhone app (currently in testing) and, once released, an Android app, and the invite pages that hosts on business plans serve from their own web addresses.

We handle personal information in line with the Privacy Act 1988 (Cth) and the Australian Privacy Principles, and this policy is how we do it. It applies to everyone whose personal information we hold: hosts, guests, co-hosts, and people who ask to hear from us before we’ve opened sign-up.

Three words we use throughout. A host is somebody with a HeadsUp account who builds an event and invites people to it. A guest is somebody a host invites. Guests never create an account with us and never pay us anything. A co-host is a host who’s been invited to help run one event they don’t own. Personal information and sensitive information have the meanings the Privacy Act gives them.

This policy forms part of our Terms of Service. Where the two say different things about the contract between us, the Terms win. Where they say different things about your information, this policy wins. This policy is free. If you’d like it in another form, email us and we’ll do what we reasonably can.

2. If you’re a guest and you just followed a link

You’re reading this because somebody invited you to something using HeadsUp, and you want to know what that means for your details. Here’s the short version.

• The host typed or imported your name and your mobile number or email, or you added yourself through a public event link, or a friend added you as their plus one. The host is the one who decided to invite you. We sent the message for them.
• The link you followed is yours alone. It’s a long random code nobody can guess. Anyone who has it can see the invite and respond as you, so don’t forward it.
• We record that your link was opened, and how many times, so the host knows their message arrived. We don’t record where you were or what device you used when you opened it.
• Anything you add on the page (your RSVP, dietary needs, poll votes, questions, a plus one) goes to the host. Some of it may be visible to the other guests, and section 6 says exactly what.
• If the host has put private details behind a verification step, we’ll send a six-digit code to the number or email the host holds for you before we show them.
• Every text and every email carries your link, and the page it opens has a stop switch for each. Every email also carries an unsubscribe link, and one tap on it stops that host’s emails about that event. You can stop straight away, with no code and no account.
• To see what we hold about you or to be erased, email support@headsup.rsvp from the mobile number or email address the invite came to, and say which event or who invited you. We’ll tell you what’s there within five business days and erase it without waiting for the host. Section 15 has the detail.

3. What we collect about hosts

Your account. Your email address, which is required, and your name if you give it. Your password is stored by Amazon Cognito, our identity service, as a one-way hash. Nobody, us included, can read it. We keep a record of the invitation code you signed up with for a short time after it’s used.

How you’d like to be told things. Which of your events’ activity (RSVPs, questions, plus ones, polls, everything else) you want to hear about, and by which channel: text, email, or push notification. If you choose texts, the mobile number you’d like them sent to. If you use the iPhone app and allow notifications, the device token Apple issues so we can reach that phone, up to ten devices per account.

What you build. Your events, the invite content and design you write or generate, the photos, logos and share images you upload, saved themes, and any updates you post. Uploaded images are served from unguessable addresses on our own domain, but anybody who has an address can view the image, so don’t upload anything you wouldn’t want a guest to see.

Business plan details. If you ask for your own text sender name, we collect the details the Australian sender ID register needs to lodge it: your legal entity name, ABN, entity type, website, business address, how you’ll use the sender name and your expected volume, and the name, email, phone and role of the person you name as your authorised representative. If you ask for a custom web address for your invites, we hold the domain name and the technical records that connect it to us.

Payments. When we start selling plans and text packs, Stripe takes your payment on its own checkout page. Your card number, expiry and security code never reach us. We hold a Stripe customer reference for you, a record of each purchase (what you bought, the amount, the date, its status, and Stripe’s reference numbers), and a mirror of your plan’s renewal state. Stripe receives your email address and your account’s internal id from us. Anything else you type on Stripe’s page, like a billing name or address, is held by Stripe, not by us.

Usage and money records. A log of every text and email sent from your account (which event, which guest, the destination number or email, how many text segments it cost, which carrier, and whether it arrived), a ledger of every movement of your text balance, your plan and allowances, and a record of anything our staff did on your account (a plan granted, a complaint answered, a person erased). The log holds your message template, never a guest’s link or a verification code.

Support. When you report a problem from inside the app, the message you write, the page you were on, which browser and device you’re on, your window size, your email, your retrace notes, and up to three screenshots you attach go to our support inbox as an email. The screenshots stay in our storage until we delete them. We don’t keep a separate database record of the report.

Connected CRMs. If you connect HubSpot (or Salesforce, once we switch it on), we hold a refresh token for that connection (never an access token), the scopes you granted, your account’s label and id at the provider, and when we last read from it. Section 8 covers what we read.

How you found us. If you arrived through a campaign link, we keep the campaign tags from that first visit (the utm parameters and the Google or Facebook click ids, and the page you landed on) in your browser and attach them to your account, and to your record at PostHog, when you create it, so we know which marketing worked.

Product analytics. We record a small set of facts about how hosts use the product (an account was created, an event was created, guests were added and how many, an invite was sent by which channel, a plan limit was hit) against your account id and email. Section 10 names the provider. Nothing about a guest, no invite content and no message body is included.

Keep me posted. If you ask to hear from us, for example about HeadsUp launching in your country, we hold your email, the country you gave and which page you asked on. We use them to send you that news, and we count the countries people ask from to decide where HeadsUp launches next.

4. What you upload about guests

When you add somebody to an event or your People directory, you hold:

• a name, a mobile number, an email address, or both, and the group tags you put them in,
• your own private note about the guest, which nobody but you and your co-hosts sees. Our terms tell hosts not to record anything about a person’s health, religion, sexuality, ethnicity or the like in a note without that person’s agreement,
• where the person came from: typed in one at a time, pasted, a CSV file, your phone contacts, a public event link, a plus one, or a CRM import,
• whether you affirmed that the person is happy to hear from you, and when. Every bulk import stops until you tick that affirmation, and we stamp the date, so there’s a record if anyone ever asks,
• an append-only history of everything that happened to the record: created, imported, invited to an event, a field changed (with the old and new values), removed, binned, restored, merged, added to the do-not-contact list, a deletion requested or cancelled, and who did it (you, the guest themselves, our staff, or the system).

You can read the whole history. Nobody can edit it, our staff included. Section 15 explains what happens to it when a person is deleted.

You’re responsible for the people you add. Our terms require you to add only people who’d expect to hear from you, and a host who uploads a list of strangers is in breach of them. If you’re a guest who thinks that happened, section 16 is your route.

5. What we collect from guests directly

Everything in this section is something a guest chooses to do on their invite page. A guest never has to do any of it.

Your RSVP. Going, maybe, or can’t make it, and when you answered. If you change your mind, we keep the earlier answers too, so the host can see the change.

Dietary needs. The host can offer a list of options and an “Other” field where you can type anything. We collect this only because you enter it, and we use it for one thing: showing the host so they can cater for you, and counting it into the host’s totals by need. What you type there can reveal something about your health or religion, which the law treats as sensitive information. You only ever give it if you want to, and by entering it you agree we can hold it for that purpose. If you’d rather not, leave it blank and tell the host some other way.

Hide my name. If you tick it, other guests see you as “Someone” everywhere on the page. The host always sees your real name.

Poll votes, potluck plates, sign-up claims, chip-in marks, poll options you add. One entry per guest per item. Your name is stamped on each so the host knows who said what.

Questions to the host. Up to a thousand characters each. The thread is private between you, the host and their co-hosts. If you tell the host something sensitive in a question, we hold it only to carry it to them. It stays on the event until the event is purged. Ask us and we’ll remove it.

Plus ones. A name and, optionally, an email or mobile for the person you’re bringing. They become a guest with their own link, which we send once at your request, and their record says you added them. We don’t treat that as their consent to hear from the host again: their record says nobody has affirmed it, and their link carries the stop controls like anyone else’s.

Joining through a public link. If the host shared an open event link, you type your own mobile or email and pass a six-digit code sent to it. Your record then says you added yourself and verified your own contact. If the host has turned on approval, your details are held while the host decides, and you see the invite only once they approve. To stop abuse of that door, we keep a hashed form of your device’s IP address for two hours. We don’t keep the address itself.

Verification. When you pass a six-digit code, we record when, the contact you proved (the number or email), and which channel it came by. We then give your browser a device key that lets it skip the code next time. We keep only a cryptographic hash of that key, at most eight per guest, and the key itself lives in your browser’s local storage. If the host later changes the number or email they hold for you, every verification is cancelled, because it was proved against a contact that’s no longer yours on that invite.

Opening your link. When and how many times your personal link was opened. That’s all. We don’t record your IP address, your device or your browser for an open, and a link preview fetched by a messaging app doesn’t count as one.

Stopping texts. If you stop texts from the page, we record when. Stopping needs no code and is never refused. Turning texts back on needs a passed code. Stopping covers the host’s invites, updates and reminders. A code you ask for yourself, to reveal private details or to join, still comes by text, because tapping for it is your own request.

Stopping emails. Every email a host sends you through HeadsUp carries an unsubscribe link, and your invite page has a switch that stops emails about that event. An unsubscribe applies to the event the email came from. To stop every email from a host, ask the host to add you to their do-not-contact list, or write to us at support and we’ll do it. If you stop emails, we record when. Stopping needs no code and is never refused, and the link in an email keeps working for at least 30 days after it was sent, even if the host has since given you a new link. Turning emails back on needs a passed code. Stopping covers the host’s invites, updates and reminders. A code you ask for yourself, to reveal private details or to join, still comes by email, because tapping for it is your own request.

Delivery. If your email bounced or your provider reported one of our emails as spam, or a text to you failed, we record when, so the host doesn’t keep trying.

Check-in. If the host scans your door pass at the event, we record when.

6. What other guests can see

Other guests on the same invite can see: the list of who’s going (names, unless hidden, up to a hundred), the names on potluck plates and sign-up slots, poll options guests have added, poll totals when the host turns them on, and how many people have chipped in.

Other guests never see: a hidden guest’s real name, who chipped in, how anyone voted, your questions, your plus one’s details, anyone’s contact details, or the host’s notes. Details the host has put behind verification (an address, a PayID, a phone number, or a whole locked tab) are never shown to anyone who hasn’t passed a code, on any channel, and a gated address is never written into a calendar file.

The public page for an open event link hides every guest name, whatever the guest chose.

7. Co-hosts

You can invite other people, by email, to help run one event. To invite them, you give us their email address. We hold it for fourteen days for the invitation alone, and it’s deleted when the invitation is accepted, declined, cancelled or expires. A co-host is a HeadsUp account holder in their own right and this policy covers them as a host.

A co-host sees that event’s content, guests, sends, responses, updates, verification-gated details and guest questions, the same as you. They can hear about that event’s activity through their own notification choices, by email and push but never by text.

A co-host can’t see your email, name, notification settings or phone number, your People directory, your do-not-contact list, your plan or billing, or anything about your other events. When a co-host adds a guest, the guest is filed on the event only and touches nobody’s directory. When a co-host sends a text or generates a design, it’s paid from your balance and recorded against your account with the co-host’s display name as the actor.

While the editor is open, the other people editing can see your display name, that you’re present, and which part of the invite you’re editing.

8. CRM imports on your own connection

A host on a business plan can connect a CRM (HubSpot today, and Salesforce once we switch it on) and import contacts from it. This is an import, never a sync: we read on request when you press import, we never write anything back, and nothing runs in the background.

From HubSpot we read first name, last name, email, phone, mobile, company, and the two fields that say whether the person has opted out of email or marketing. From Salesforce, once available, we’ll read the equivalent fields plus its do-not-email and do-not-call flags. We drop every row the provider marks as opted out before you ever see it, and every row without a usable name or contact way. What’s left comes to your screen, and nothing is saved until you affirm consent the same way as any other import.

The connection is between you and your CRM. The provider acts on your grant, not ours, and its own privacy policy governs what it sees. Disconnecting revokes our access at the provider and deletes the connection on our side, and disconnecting is never blocked by your plan.

9. Why we use each kind of data

We collect and use personal information only to run HeadsUp. Plainly:

• To send invites and updates. A guest’s name and contact are used to address the message the host asked us to send.
• To run the invite page. RSVPs, dietary needs, votes, plates, claims, questions and plus ones exist so the host can run the event and, where section 6 says so, so guests can see each other’s answers.
• To protect private details. Verification contacts and hashed device keys exist so an address or a payment detail is shown only to the person the host meant it for.
• To honour a stop. Opt-out stamps and do-not-contact entries exist so a person who said stop isn’t messaged again.
• To keep hosts honest. The consent affirmation and the People history exist so that if a guest complains about how they were added or messaged, there’s a record that answers it.
• To keep the service safe. We use records to detect and stop abuse, investigate a complaint that a host added people who didn’t expect it, enforce our terms, and protect our systems.
• To run your account. Your email is how you sign in and how we reach you about your account, your events, and changes to the service. Your notification choices decide what else we send you.
• To bill you and keep the books. Purchase and ledger records exist to charge you correctly, answer a billing question, and meet our record-keeping obligations.
• To help you when something breaks. Support reports and their screenshots are used to fix your problem.
• To make the product better. The product analytics in section 3 tell us which features get used and where hosts get stuck. We look at this in aggregate.
• To know which marketing works. First-touch campaign tags and the analytics on our marketing pages tell us where new hosts come from.
• To tell you about HeadsUp. We may email hosts and people on the keep-me-posted list about new features and news. Every such email tells you how to stop them, and asking stops them at once. Service messages about your account and your events aren’t marketing and keep coming while you have an account. We never market to guests of other hosts’ events. When HeadsUp itself hosts an event, its guests are our guests, and we may text them afterwards to say thanks, with an offer such as a free month of a paid plan. If you ask one of us in person for an offer like that, we text it to the number you give us. We note when the link in an offer text is opened, whether it’s redeemed and by which account, and whether the offer was used, so we know the offer reached you. Every such text carries a link that stops them, and tapping it stops them at once.
• To generate designs and drafts when you ask. Section 10 explains what goes to the AI provider.

We may also use information where the law requires or permits it, for instance to answer a lawful request from a regulator, or to establish or defend a legal claim.

We don’t sell personal information to anyone. We don’t use anything you or your guests give us to advertise to you or anybody else. The one thing an advertiser sees is Meta’s ad measurement (section 10): on our marketing pages, the try-it page and the sign-up page, it tells Meta that a visitor viewed the page or created an account, so we can see which of our own ads work and Meta can show them to people likely to want them. Nothing from inside the app and nothing about a guest ever reaches it. We don’t build profiles of guests. We don’t send guests anything except what a host asked us to send, an invite to a plus one that another guest asked to bring, the verification codes they request, a reply if they write to us, and, to guests of an event HeadsUp itself hosted or to somebody who asked us in person, the offer described in section 9.

If we want to use your information for a new purpose you wouldn’t reasonably expect from this section, we’ll ask you first.

10. Who we share it with

We share personal information only with the providers we need to run the service, each for the job named here. Each of them is bound by its own terms with us, and none of them is allowed to use what we send for anything but the job named here, except Google, whose analytics and map embed run under Google’s own terms, and Meta, whose ad measurement runs under Meta’s own terms.

Provider	What it does for us	Where	What it sees
Amazon Web Services (AWS)	Hosts our database, file storage, identity service, email sending, our fallback text route, push delivery, servers, and the content delivery network that serves our pages and images	Sydney, Australia, for storage, identity, email and processing. Content delivery caches our pages’ static files and images at AWS edge locations in Australia, New Zealand, Singapore, Japan, the United States, Europe and elsewhere, listed at aws.amazon.com/cloudfront/features	Everything we store. Email recipients and message bodies. Push tokens
Our keep-me-posted list	The landing page’s own AWS table, holding the entries described in section 3	AWS, Sydney	Email, country and which page you asked on
Google Workspace	Hosts our support inbox, so support reports, screenshots and anything you email us	Google, United States	Whatever you put in the report or the email, which can include a screenshot of a guest list
touchSMS	Our default text message carrier, sending under the registered sender name “HeadsUp” or a business host’s own registered name	Australia. It’s an Australian carrier, and we’re confirming with it that nothing is processed offshore	The recipient’s mobile number and the text we send, plus a reference of ours for delivery receipts
Stripe	Takes payments and runs the receipts, invoices and billing portal	Stripe is headquartered in the United States and may process your payment details there and in other countries under its own privacy policy (stripe.com/privacy)	A host’s email address and account id from us. Whatever the host types on Stripe’s own checkout page, including card details, which Stripe holds and we never see
Google Analytics	Measures traffic and sign-up funnels on our marketing pages, the try-it page and the sign-up page only	United States	Page views and funnel events on those pages. Invite links and sign-up codes are stripped from every address before it’s sent
Meta (Facebook, Instagram)	Measures which of our Facebook and Instagram ads lead to sign-ups, on our marketing pages, the try-it page and the sign-up page only	United States	A page view on those pages, and a note that an account was created, with the page’s address and the page you came from. It never loads when either address holds an invite link or a sign-up code
PostHog	Product analytics about how hosts use the app, sent from our servers only	United States	A host’s account id and email, the campaign tags from their first visit (section 3), and the product events listed in section 3. Nothing about a guest
Anthropic	Generates invite designs and first drafts when a host asks	United States	The host’s prompt, the event’s name, the current design settings and the reference photo. Detail below this table
Apple	Delivers push notifications to the iPhone app	United States	The device token, the event’s title, and a one-line notice that names the guest who replied, asked or added a plus one
Google (Firebase)	Will deliver push notifications to the Android app once Android push is switched on. It isn’t yet, and Google receives nothing today	United States	Nothing today
Google Maps	Draws the map inside a location block on an invite page	United States	When a map renders, your browser fetches it from Google directly, so Google sees that request the way it sees any map embed. We send Google nothing about who you are
HubSpot, Salesforce	Sources a host imports contacts from, on the host’s own connection (section 8)	United States	These providers see that our app read the host’s contacts. We are the recipient, not the sender

Two things this table means for guests. Nothing about a guest goes to Google Analytics, PostHog, Meta or Stripe. The third parties a guest’s details reach are AWS (storage and email), touchSMS (texts), Apple (your first name in a push notice, if the host uses the iPhone app), Google Maps through your own browser if the host put a map on the page, Google Workspace, our mailbox provider, if a host’s support screenshot shows you, and Anthropic only if the host put your name in the event’s name.

What goes to Anthropic. When a host asks for a generated design or a first draft, we send the words the host typed, the event’s name, the current design settings if they’re refining one, and the reference photo if they attached one. We never send guest lists, RSVPs, contact details or anything a guest wrote. The event’s name goes, so if you named a person in it, that name goes too, and a reference photo goes as you uploaded it, people included. The photo is kept by us for thirty days and then deleted. Anthropic handles what we send under its commercial terms. Under those terms it doesn’t train its models on our inputs, and it deletes what we send within 30 days. Our try-it page and local mode use a canned sample and never contact Anthropic.

Sender name registration. If a business host asks for their own text sender name, we pass the registration details in section 3 to our carrier and the Australian sender ID register so the name can be lodged in the host’s name. The person you name as the authorised representative will be contacted by our carrier directly and asked to confirm their identity with photo ID, because the register holds that person, not us, responsible for the sender name. The request is also emailed to our support inbox.

Our staff. A small number of our staff can look up a person by their exact mobile number or email to answer a complaint or a support request. Values come back masked, and revealing them writes a line in that person’s history and in the account’s audit trail. Staff can read an account’s send log in full to answer a delivery question, and that read is not individually recorded. Staff can read an account’s billing records to answer a billing question. Staff never browse directories.

When the law requires it. We’ll disclose personal information if a court order, warrant or law requires us to, and we’ll tell the affected person unless the law prevents it.

If we’re sold. If HeadsUp RSVP Pty Ltd is acquired, merges, or its business is sold, including by an administrator or liquidator, personal information would pass to the new owner only on the same terms as this policy. We’d tell hosts by email beforehand where we’re able to, and the invite page would link to the new owner’s policy.

11. Overseas disclosure

Our database, file storage, identity service, email sending and processing are all in AWS’s Sydney region, and our default text carrier is Australian. Your information stays in Australia except where section 10 says a provider is overseas:

• Google Analytics, Meta, PostHog and Stripe receive information about hosts and marketing visitors in the United States, never about guests.
• Anthropic receives a host’s prompt, event name and reference photo in the United States. The only guest data that can ride along is a name a host put in the event’s name or a face in the photo.
• Apple receives a host’s push token and a short notice that can carry a guest’s name, in the United States.
• Google receives a guest’s browser request when a map renders on an invite page.
• Our support inbox is Google Workspace, in the United States, and a host’s screenshot can carry guest names.
• A host’s connected CRM is wherever that host’s CRM is.
• AWS’s content delivery network caches the page’s static files and images at the edge locations named in section 10 so they load quickly. Your invite’s details are fetched from Sydney each time.

We haven’t negotiated special terms with any of these companies. We use each on its standard terms, we’ve read them, and section 10 says what each one sees. Each is bound by the laws of the country it sits in, and a court there could compel it.

12. Cookies and local storage

We set no cookies of our own. Google Analytics sets its own cookies (named _ga and similar) on the surfaces it runs on: our marketing pages, the try-it page, and the sign-up page. Meta’s ad measurement sets its own cookie (named _fbp) on the same surfaces. Neither runs on an invite page or inside the app after you sign in.

In the host app, we use your browser’s local storage to keep you signed in, remember which tours you’ve seen, hold your push registration, hold the first-touch campaign tags described in section 3, and, in the try-it playground, hold the sample data you’re playing with. The try-it page keeps its sample data in your browser and sends nothing to our servers. Google Analytics and Meta’s ad measurement still run on it, as above.

On an invite page, the only thing we store in your browser is the device key you’re given after passing a verification code, so you don’t have to pass another. Clearing your browser’s storage means verifying again. Nothing else is stored and nothing tracks you.

13. Security

Here’s what actually protects it:

• Everything between your browser and us, and between us and our providers, is encrypted in transit. Our database and file storage are encrypted at rest. A text message itself travels the mobile network the way every text does, which is not encrypted end to end, so treat the link in it as private.
• Every guest link is a long random token that can’t be guessed. A link on a binned event stops working the moment it’s binned. A host can rotate a guest’s link, which kills the old one at once.
• Verification codes are stored hashed, expire in ten minutes, and are capped in how often they can be requested and how many guesses they allow. Device keys are stored as hashes only.
• Every host request is checked against the event’s ownership on every call. Actions reserved for an event’s owner are refused to a co-host.
• Your password is stored by Amazon Cognito, our identity service, as a one-way hash. Nobody, us included, can read it. Passwords must be at least twelve characters.
• Our application logs never carry phone numbers, emails, message bodies, links, codes or names, and are kept for one week. We don’t keep access logs of who viewed which invite page, and we’ve configured our providers to keep none for us.
• Invite pages are marked not to be indexed by search engines.
• Our staff look people up by exact number or email, never browse, and values in a People lookup come back masked with any reveal recorded. Section 10 says what else staff can read.
• Our production database keeps thirty-five days of point-in-time backups so we can recover from an outage.

No system is perfectly secure. Section 18 explains what we do if something goes wrong.

14. How long we keep things

We keep personal information only as long as we need it for the purposes in section 9, or as long as the law requires. The real periods:

What	How long
Your account, events, content, guests and People directory	Until you delete them, or until you close your account and we complete the erasure (section 15)
The send log (every text and email, its destination and outcome) and the text balance ledger	Two years, then deleted automatically
Purchase, subscription and billing records	Seven years after the purchase, the period company records must be kept in Australia, then deleted
Our staff’s audit trail on your account	Seven years, then de-identified
Verification codes	The code expires in ten minutes and the record is deleted within an hour
The hashed IP address from a public link join	Two hours
Send run working records	Thirty days after the run finishes
Text delivery receipts	Thirty days
An offer text from HeadsUp: its link, holding the last nine digits of the number it went to, when it was opened, and the account that redeemed it	At least 400 days from the text, and until a month after the offer could last be used, so its stop link keeps working long after the offer ends
The record of who a HeadsUp offer text was sent to: the name and number, and when it went	The same as its link, so our staff can see whether each offer was used
A request to stop HeadsUp offers, holding the last nine digits of the number	For as long as we send offers at all, because deleting it would start them again
A binned event	Thirty days after you bin it, then everything on it (guests, RSVPs, votes, plates, claims, questions, updates, uploaded images) is deleted by a daily sweep. Restoring it inside the thirty days brings all of it back
A person you’ve asked to delete permanently	Erased from your People directory thirty days after you ask (section 15). Their row on any event they’re still a guest on stays until you remove them from it or the event is purged
An erased person’s history, with its values gone	Seven years after erasure, then deleted
Your do-not-contact list	For as long as your account exists and two years after it closes, or until the person on it asks us to remove them
Uploaded photos, logos and share images	Stop being served when you replace them or when their event is purged, once nothing else references them. A copy stays in our storage until we clear it. Ask and we will
Reference photos for AI generation	Thirty days
Support report screenshots	Kept in our storage until we delete them. Ask and we will
Co-host invitations, sign-up invitations	Fourteen days, then they expire and are deleted
Editor presence and edit locks	Three hours
CRM connection	Until you disconnect
Application logs	One week
Database backups	Thirty-five days. Anything erased can persist in a backup for up to thirty-five days before it’s gone everywhere
Google Analytics event data	Fourteen months, on Google’s systems
Keep-me-posted entries: email, country and where you signed up	Until you ask us to remove you

Removing a guest from an event is immediate and permanent for their row. The send log still shows for two years that a message went to their number or email, because that’s the proof a message was sent and it can’t be edited.

15. Deletion, and exactly what survives it

This is the section to read if you want something gone.

If you’re a guest and want to be erased. Guests aren’t our customers and have no account to act through, so this route is yours, and it doesn’t wait the host’s thirty days. Email support@headsup.rsvp from the mobile number or email address the invite came to and, if you can, say who invited you or what the event was, because we look people up one host account at a time. We’ll tell you what that host holds and erase your details from their People directory straight away. Your name and contact stay on any event you were invited to until the host removes you or the event is purged, so tell us if you want us to ask the host to do that too. Two things survive: the send log’s record that a message went to your number or email, for two years from the send, and any do-not-contact entry for you, which keeps you unmessaged. If you’d also like to make sure that host can never message your number again, say so and we’ll see it’s put on their do-not-contact list, which outlives your record. Ask and we’ll have a do-not-contact entry removed too. If you’d rather be removed from one host’s events but not another’s, say so. We can’t erase you from a host’s own phone or CRM, since we never held those.

When you remove a guest from an event. Immediate. The guest’s row is deleted and their personal link stops working. Plates, sign-up claims, poll votes, chip-in marks and questions they added stay on the event, still carrying their name, until the event itself is purged.

When you bin an event. The event and everything on it stop being reachable at once and are deleted for good thirty days later, unless you restore it.

When you remove somebody from your People directory. The person moves to a Deleted tab. Nothing is erased and you can restore them at any time. This exists so a slip of the finger doesn’t lose somebody.

When you delete somebody for good. This starts a thirty-day clock, and the request itself is written into the person’s history. A restore or a cancel calls it off at any point during the thirty days. When the clock runs out:

• The person’s name, mobile number and email address are erased from your People directory, along with the detail of where they came from (a file name, a CRM account label, or the name of the guest who added them) and the consent affirmation date. The kind of door they came through (typed, a file, your phone, a public link, a plus one, a CRM) stays.
• Every value inside their history is erased: every old value, every new value, every note.
• What stays: the shape of their history (that a change was made, when, to which field, by whom, on which event), left carrying the name “Erased person” and identifying nobody, their row on any event they’re still a guest on, until you remove them from it or the event is purged, and the send log line saying a message went to their number or email, for two years.

We keep that shape on purpose, and we’d rather say so plainly than have you infer it. It exists to answer a complaint about how a host behaved. If somebody writes to us saying they were added to a list without their consent and messaged, and the host deleted them the day before, the thirty-day delay and the surviving shape mean we can still see that the person was imported from a file on one date, invited on another, and deleted the day the complaint came in, without holding anything that says who they were. Deleting somebody is never a way to delete the record of what you did with them.

Do-not-contact entries outlive everything. Your do-not-contact list is keyed on the mobile number or email itself, not on the person’s record, precisely so that erasing or merging the person can’t undo it. Deleting somebody is never a way to start messaging them again, and a promise not to message a number outlives the record of the person who had it.

Closing your account. Email support@headsup.rsvp from your account’s email address. We’ll disable sign-in the same day. The rest is done by hand and may take up to thirty days: we bin every event you own, so it’s purged on the usual thirty-day clock with everything on it and every image, we erase every person in your directory the same way as a permanent deletion above, we erase your own account details, and we end your co-host membership of anybody else’s events. The send log keeps its lines for the rest of its two years, with the shape of your account behind them. Your purchase records are kept for the seven years in section 14, and the audit trail of what our staff did on your account is kept for the same period. A closing account is not a route to destroying the record of how its guests were treated.

What deletion can’t reach. Anything erased can persist in a database backup for up to thirty-five days before it’s gone everywhere. A removed image stops being served at once, but a copy stays in our storage until we clear it, and we will if you ask. Messages already delivered to a guest’s phone or inbox are theirs. Records our providers hold under their own retention rules (a text carrier’s delivery record, a payment processor’s transaction record) are governed by their policies.

16. Access, correction and complaints

If you’re a host, almost everything is self-serve. The Account screen holds your email, password, notification choices, branding, push devices, CRM connections, do-not-contact list, and your billing portal. The People screen holds every saved person with their consent record and full history, and lets you edit, bin, restore or delete for good. Every event’s Guests and Responses screens hold every guest row, and an export downloads your roster. Changing your email address is verified through a code to the new address.

If you’re a guest, your personal link lets you change your RSVP, dietary answer, hide-name choice, poll votes, plates, marks, claims, questions and plus ones at any time, and stop texts. You can see your name on the page but can’t change it, and you can’t see or change the number or email the host holds for you. If any of it is wrong, write to us or ask the host. If you write to us we’ll have it corrected, or if we decide not to (for instance because we can’t confirm it’s you) we’ll tell you why in writing and how to complain. A corrected contact cancels any verification proved against the old one. For anything else, including a copy of what’s held about you, write to us.

Writing to us. Email support@headsup.rsvp. We’ll acknowledge within five business days and give you a full answer within thirty days. We’ll need to confirm you’re the person concerned, which for a guest means writing from, or otherwise proving control of, the number or email the invite came to. There’s no charge for any of this. We can decline a request where the law allows, for instance a request to see somebody else’s guest list. If we refuse any part of a request we’ll tell you in writing why, and how to complain about the refusal.

Complaints. If you think we’ve handled your information in a way that breaches the Australian Privacy Principles, email support@headsup.rsvp with “Privacy complaint” in the subject. We’ll acknowledge it within five business days, investigate, and answer within thirty days. If you’re not satisfied with our answer, you can complain to the Office of the Australian Information Commissioner (OAIC) at oaic.gov.au or on 1300 363 992.

17. Decisions our systems make on their own

Some things happen without a person looking. Here is each one, and what it uses:

• Dropping opted-out CRM rows. When a host imports from a CRM, rows the provider marks as opted out of email or marketing are dropped before the host sees them. Uses the provider’s opt-out flags.
• Not sending to somebody who said stop, or who can’t be reached. A host’s send skips a guest who stopped texts, whose email bounced or was reported as spam, whose last text failed, or whose number or email is on the host’s do-not-contact list. Uses the stop stamp, the delivery outcomes and the do-not-contact list.
• Capping attempts. Verification codes, public-link joins and guest actions are limited in how often they can be requested or tried. Past the cap, the next try is refused until the window passes. Uses counts and timestamps only.
• Holding a joiner for approval. If a host has turned approval on, a person who joins through a public link or is added as a plus one is held, and shown a concealed page, until the host decides. Uses the host’s setting and the time the person joined.
• Plan caps and lapses. What a host can add, send or turn on follows their plan, and a plan that has ended falls back to the lower limits after fourteen days. Uses the host’s plan state and usage counts.

None of these decides anything about a person’s character or creditworthiness. If you think one of them got it wrong, write to us and a person will review it. This section applies from the day it’s published and in any case no later than 10 December 2026.

18. If there’s a data breach

If we think personal information we hold has been lost, seen or taken by somebody who shouldn’t have it, we’ll assess it within thirty days, and usually much faster. If it could seriously harm anyone, we tell the Office of the Australian Information Commissioner and every person affected as soon as we can, and we tell them what happened, what was involved and what to do. We’ll act as if the Notifiable Data Breaches scheme applied to us, whatever our size. Guests hear from us directly, at the contact the host holds for them, not through the host. If the breach touches an event run by a host who’s a business, we’ll tell that host as well, so they can meet their own obligations.

19. Children

HeadsUp accounts are for adults. You must be eighteen or older to create an account, and we don’t knowingly hold an account for anyone younger. Guests can be any age, because a host can invite whoever they like to a child’s birthday party, but the invitation goes to the mobile number or email the host holds, which for a child is usually a parent’s or carer’s. Where a guest is a child, we treat the adult who holds the phone or inbox the invite went to as the person answering for them, dietary needs included. If you’re a parent or carer and you’d like a child’s details erased from an invite, section 15 applies and you can write to us on their behalf.

20. Anonymity

You can visit our marketing pages and use the try-it playground without telling us who you are. A host needs an email address to have an account, because it’s how we reach you and how you get back in. A guest can hide their name from every other guest, but not from the host, because the host is the one who invited them.

21. Changes to this policy

We’ll update this policy when the product changes in a way that affects what we hold or how we use it. The date at the bottom is the date of the current version. If a change matters to hosts, we’ll tell them by email or in the app before it takes effect. If a change matters to guests, the invite page will link to the current version. Nothing we’ve promised here about deletion or about not selling data will be walked back for information we already hold without asking you first.

22. Australian law

This policy is read under Australian law. The Privacy Act 1988 (Cth) applies to how we handle your information wherever you are.