Privacy policy

Who we are

We are the controller of the personal information described below. This policy is written to meet Canada's PIPEDA and, where it applies to you, the GDPR and the UK GDPR.

The important part: we hold it and we cannot read it

When you build a game you type in a child's name, their age, the names of people in the room and the gifts you are offering. When you plan the day you add a guest list, allergy notes and an address.

If you keep a party in an account, a copy of it does reach us. It reaches us as ciphertext. Your browser locks it with a key derived from your password, on your own device, and that key is never sent to us and never leaves that browser in a form we could use.

The link is separate. A game link carries the whole party in the part of a web address after the # character, and browsers, by design and by specification, never transmit that part to any server on their own. It stays in the address bar on your device and on the device of whoever you send it to.

There is one exception, and it is the one place we can read a party. When you pay for a game, your browser locks a copy of that game link to a key held only by the owner of KidBD and sends us the locked copy, so that if you lose the link we can send it to you again. Our server only ever receives and stores the locked copy and cannot open it. The key that opens it never touches our server: it lives in one admin browser, itself locked by a passphrase. That means the owner of KidBD can open the game link of a party you paid for, and with it read what the game holds: your child's name, their age and what you typed into it. We open one only to help you with that party, and every opening is recorded. A party you do not pay for is never sent.

Exactly what is on our server

This is the whole list. If you hold us to one section of this policy, hold us to this one.

What is not on our server, in any readable form: your child's name or age, the challenges you picked, the gifts you wrote, who is coming, what anybody is allergic to, and where the party is. There are three exceptions, all in the rows above. A paid game link: its locked copy can be opened by the owner of KidBD, only to resend it or help you with that party. A checkout you did not finish: until you pay, press stop or the day passes, we can read your child's first name and the party date. And a birthday reminder you asked for: until it is sent or you press stop, we can read the first name if you gave one, with the birthday date. The other place your child's first name leaves your device is the name of the guest list Brevo keeps for us when you email invitations, set out under Email.

The follow up row of that table is worth saying in full. If you send invitations by email and switch the follow ups on, we hold each guest's address and a date. For a guest who has not answered, that is the reminder, and it is deleted when the reminder goes out or when they answer, whichever comes first. For a guest who answers yes, we hold their address until the party is over, to send a note the day before it and a thank-you after it, and then it is deleted. A guest who answers no is deleted straight away. These follow up records never hold their name, your child's name, or the invitation itself. That is why anything we send them can only ask them to open the invitation already in their inbox: we cannot send it again, because we did not keep it.

Our server never writes a request body or a link fragment to a log, and we record no device fingerprint and no location. We do measure how the pages a parent uses are used, and since 20 September 2026 that measurement is also sent to Meta, so we can tell which advertising is worth paying for. It is a short, fixed list of events with no party in it. What we send to Meta, below, sets out every field, and the ones we deliberately leave out. Since 17 October 2026 the same pages also tell Google Ads three of those moments; What we send to Google lists them.

Your password is the key, and we cannot reset it

The key that opens your parties is derived from your password inside your browser. That is what makes the sentence above true rather than a promise about our intentions.

Until you set a password, the key lives only in this browser. Clearing this browser's site data before you set one loses the account. A link you already have still opens its party, because the party travels inside it.

The sign-in link in your welcome email signs you in on any device for 30 days, and it stops working the moment you set a password or sign out everywhere.

Two things survive a lost password, and both are worth doing on the day you buy:

• A link you already have keeps working, because the party travels inside it.
• A party you saved as a file opens again in the builder on any device.

We say this next to the password field when you set it, not in a tooltip afterwards.

What is stored on your own device

Your browser's local storage holds the working copies, so a half finished party survives a reload. Apart from the partner code below, none of it leaves your browser.

• party-builder:draft - the party you are part way through building.
• party-builder:seen-guide - so the guide only opens itself the first time.
• candlequest:shelf - the parties on your shelf, held as the same codes your links carry.
• party:<name> - on the playing device, the gifts the child picked, so the screen can be shown again.
• candlequest:cred - what your password or this browser's own key derives, never the password itself, so this browser can open your account without asking.
• kb_ref - only if you arrived through a partner's link, that partner's code, as a copy of the cookie of the same name: see Partner links.

You can clear all of it at any time with your browser's "clear site data", or with the Start over button in the builder. Clearing it does not delete your account; signing in again brings your parties back, as long as you still have the password. Until you set a password, this browser's saved sign-in is the only key, so clearing it then loses the account.

Signing up, and what it costs

Creating an account carries no charge and asks for no card. It asks for an email address, and nothing else: your browser makes a random key for the account and keeps it. A password is optional, and you can set one later to open your parties on another device. There is no trial that starts a clock, and making an account never begins a charge.

You pay per party, when you decide to send a real link, and that payment unlocks that party's game link and its planner together. There is one price, $39, and it is charged once.

No card is kept on file, by us or on our behalf. There is no subscription here, so there is nothing for a card to be kept for: the card details go to Stripe, never touch our pages or our server, and we hold no card reference of any kind afterwards.

Payment, and what Stripe sees

Payments are processed by Stripe Payments Europe, Ltd. and its affiliates. You enter your card details on Stripe's own page, not ours. We never see, receive or store your card number.

Stripe sees the payment and nothing else. It receives the amount, your card details, your email address, your name if you gave one, your country, and a short reference that says which party the payment belongs to. That reference is a random party id such as p1x9f3kq. It is not a name, and it decodes to nothing.

Stripe passes us back your email address, the amount, the country, the last four digits of the card and that reference, so we can mark the party paid and support you. Stripe is the processor for that data and has its own policy at stripe.com/privacy.

Email

We use Brevo (Sendinblue SAS, France). To you, we send four kinds of email and nothing else:

• Your purchase confirmation, containing your link.
• Reminders about a party you did not finish buying. Only if you gave us your email address and stopped at the price without paying. At most five, all about that one party: the first a couple of hours later at the earliest, and none later than the evening before the party. None on the party day or after it, and none at night in the party's time zone.
• A birthday reminder. Only if you asked for one on the front page. One email a year, 7 days before the birthday, set out under Birthday reminder.
• A note when a guest answers. If you saved a party to your account and a guest answers the invitation, we send one line, "A guest answered your invitation". At most one an hour for each party, however many answer in that hour.

Every reminder carries a one-click stop, and paying stops them too. That is the whole of what we send you. We do not run a newsletter, and we do not sell, rent or share your address. Brevo's policy is at brevo.com/legal/privacypolicy.

What the reminders keep

To send them, our server keeps, readable by us: your email address, your child's first name, the party date and the party id, plus your browser's time zone so none arrives at night. Nothing else about the party: not the age, not who is coming, not the place, not the game. This is one of two places your child's first name sits on our server in a form we can read (the other is the birthday reminder), and each reminder carries it through Brevo like any other email.

• It is deleted when you pay, when you press stop, or when the party day passes, whichever comes first. It is never kept past six months.
• A stop is remembered, the address is not. Pressing stop keeps a one-way hash of your address for 400 days, so a later visit cannot start the reminders again.
• Why we may send them. You asked us for a party and gave us your address to get it. Under Canada's anti-spam law, CASL, that request is implied consent, and it lasts six months. The stop link withdraws it at once.
• For readers in the EU and the UK. The basis is our legitimate interest in helping you finish a purchase you started. You can object at any time, and the stop link does it in one click.

Birthday reminder

If you use the birthday reminder form on the front page, it goes to our server and we store, readable by us, your name, your child's first name (only if you gave it), your email address, your phone number and the birthday date, in the same Cloudflare D1 database as the checkout reminder. We use them for one thing: one email a year, 7 days before the birthday. The phone number is only stored and we send no text messages. Every reminder carries a stop link that deletes the stored reminder, or email # and we will delete it.

What the answer note carries and keeps

• It carries nothing of the answer. A guest's answer is sealed to your account's key before it leaves their phone, and our server cannot open it. So the note has no guest name, no yes or no, no child's name and no link: you open your dashboard to read it.
• One click turns them off, for good. Every note carries a stop, as your mail app's Unsubscribe button and as a plain address at the bottom. It turns the notes off for your whole account, every party, and that switch is the one thing we keep about it, with no expiry. Answers still reach your dashboard.
• Nothing else is kept. To hold the one-an-hour limit, our server counts against the party for that hour, and the count expires with the hour. The note goes to the address on your account at the moment it is sent.

Invitations you send to your guests

If you ask us to email your guest list, we send one invitation per guest, each carrying that guest's own link. If you switched the follow ups on, a guest gets at most three more messages after it, never more than one of each, and which ones depends only on their own answer: one reminder while they have not answered, and if they answer yes, a note the day before the party and a thank-you after it. A guest who answers no gets nothing further at all. That is the whole list, and there is no fourth. A guest is never sold or shared, and never emailed about anything else, ever.

Two things about those messages, and both are the same promise the rest of this page makes:

• The invitation passes through and is not kept. The link carries the party in the part of the address after the #, and it reaches us in the body of that one message and is written down nowhere: not to a file, not to a log, not to a database.
• Send later is held by Brevo, not by us. If you pick a time instead of sending now, each invitation goes to Brevo at once with that time on it, and Brevo holds the whole message, that guest's link and address included, until the minute you picked, at most three days ahead. Our server keeps only a one-way hash of the party, the address and the time, with Brevo's number for that message, so a second press cannot send it twice. That hash expires on its own two days after the minute you picked.
• The addresses are kept, in a guest list at Brevo. Every address an invitation was delivered to is added to one list for that party, named for your child and you, for example "Ava's Guests (Mina)", or "Ava's Guests" if you gave no name. Each entry holds the guest's email address and the first name you typed for them, and nothing else: not the invitation, not their answer. This happens whether or not you switched the follow ups on.
• The follow ups keep a little more, briefly. If you asked for them, we also hold each guest's address and a date on our own server: until the reminder is sent or they answer, and for a guest who says yes, until the party is over. Every one of those records is deleted as the message it belongs to goes out.

You are giving us other people's email addresses when you do this, so it is your call to make: send the invitations yourself from the per person links instead, and we never see a guest's address at all.

If you email us for help, we keep the email so we can answer it. If you message us from the "Ask the KidBD team" panel, it opens WhatsApp with your message, and our server keeps a copy of that message, with no party link and no IP address, for 180 days so we can answer it.

What we do not do

• We measure the funnel, and we name what we send. Since 20 September 2026 this site carries a Meta pixel, and our own server sends Meta the same handful of events. Since 17 October 2026 the same pages also carry the Google Ads tag, for three events only. Since 10 October 2026 the same pages also carry Microsoft Clarity, which records how a page is used (scrolls, clicks, where people stop) so we can see what confuses people. There is no Google Analytics and no other measurement of any kind, apart from the count of visits through a partner's link set out under Partner links, and our own step count on the front page and the setup questions, which goes only to our server and is set out under Exactly what is on our server. Every field is listed under What we send to Meta and What we send to Google.
• It is on every page except the three that matter most. The pixel runs on the front page, the setup questions, the page after payment, the articles, and this page and the terms. It is not on the game your child plays, not on an invitation a guest opens, and not on your dashboard or the pages that send you on to it, because a party's whole link sits in that page's address. Those pages load nothing from Meta, Google or Microsoft. Two of them can tell Meta one thing each, and only through our own server: an invitation reports that a guest opened it, and your dashboard reports how many invitations you just sent. Your dashboard also reports that it was opened, through our server only. All three are rows in the table under What we send to Meta, and nothing after the # is in any of them.
• We may show you an ad on Meta or Google. That is what those events are for. We do not pass them to any other advertiser, and we build no profile of you on our own side.
• We never sell or rent personal information to anybody, for any amount, under any circumstances.
• We do not watch what you do and then email you about it, with one exception you can stop in one click: stopping at the price starts the reminders set out under Email. Nothing else you do here sends you anything.
• Four things load from anybody else: Meta's pixel, the Google Ads tag, Microsoft Clarity, and Cloudflare's Turnstile. The pixel, the Google tag and Clarity run only on the pages named above. Turnstile is a bot check that loads on the setup questions, the page after payment and your dashboard when you send us something only a person should, such as making an account or sending invitations; it is set out under Where your information goes. The typefaces are served from our own site rather than fetched from Google, and the game, the invitations and your dashboard load nothing from Meta, Google or Microsoft.

Five things set a cookie. Meta's pixel sets its own _fbp on the pages named above, so that the same browser is recognised across them. The Google Ads tag sets its own (such as _gcl_au) on the same pages, so Google can tell which ad click led to a purchase. Microsoft Clarity sets _clck and _clsk on the same pages to group one visit's page views, and Microsoft may set CLID and MUID on its own domains. Stripe sets its own on Stripe's checkout page, which are necessary for the payment and for fraud prevention. And our own kb_ref, only when a page is opened through a partner's link, set out under Partner links. There are no others, and none of the first four is set on the game, on an invitation or on your dashboard.

Partner links

Some people share KidBD through a partner link: our address with ?ref= and their code on the end. If you buy within 30 days of opening one, that partner earns a share of what you paid. You see nothing different, and you pay the same price. A partner link adds three things, and nothing else:

• The kb_ref cookie. Set by us, for 30 days, holding the partner's code and nothing else: not who you are, not your party. A copy of the same code sits in your browser's local storage in case the cookie is cleared, and a newer partner link replaces both. When you go to checkout, the code goes with it, so the right partner is credited.
• A daily count of visits for each partner code. Opening a partner link adds one to that code's total for the day on our server. It is one number per code per day. It holds no IP address, no device, no page address and nothing after the #, so it cannot tell one visitor from another. Each day's total is deleted after 13 months.
• Which code a checkout carried. When you go to checkout with a partner code, our server notes the code against a random id for that party and purchase, so the sale can be credited. It holds nothing about you, and it is deleted after 45 days.

These are the one exception to our rule against measurement of our own, made on Kavalsia Inc.'s explicit instruction on 19 October 2026. Opening the site without a partner code sets neither.

What we send to Meta

We buy advertising on Facebook and Instagram. To know which of those ads actually leads to a party being made, Meta has to be told when it happens. That is the whole reason this exists, and it is the one place on this site where something about you leaves us on purpose.

It runs on every page of this site except three: the pixel does not run on the game your child plays, it does not run on an invitation, and it does not run on your dashboard (nor on the pages that redirect to it). The first two are the ones a child and a guest open; the third is the page a party's own link opens into. None of the three loads anything from Meta. Each of them tells our server one thing, which our server passes on to Meta without anything after the #: an invitation that a guest opened it, your dashboard that it was opened and how many invitations you sent. All three are rows below.

The main events are sent twice: once by the pixel in your browser, and once by our own server, which is more reliable. The two carry the same identifier so that one thing that happened is counted once.

What is never sent, and cannot be: your child's name, the date, the time, the place, who is coming, what anybody is allergic to, the challenges you picked, the gifts you wrote, the invitation, or the link to the game. Our server forwards a fixed list of fields and drops everything else before the request leaves, so this is a property of how it is built rather than a promise about how we behave.

What we send to Google

We also advertise on Google. Since 17 October 2026 the pages that carry the Meta pixel also load the Google Ads tag, and it reports three moments and nothing else. The game, an invitation and your dashboard never load it.

No name, date, place, guest, email address or link to the game is sent to Google. Any content blocker stops all of it, and Google's own My Ad Center controls what they do with it.

Children

This service is sold to adults. It is designed to be bought by a parent or guardian and played by a child under that adult's supervision. We do not knowingly collect personal information from children.

A child playing the game does not create an account, is never asked for a name, an email address, an age or a photograph, and nothing they tap is transmitted anywhere. Their picks are written to that device's local storage so the final screen can be shown again, and nowhere else.

The child's name and age that appear on screen were typed by you. They travel inside your own link, and the copy of the party we hold is locked with your key. The two exceptions are the first name on a checkout you did not finish and the one on a birthday reminder you asked for, both set out under Email.

The same is true of a guest. A guest's parent replying to an invitation seals their answer, including an allergy line, to your public key in their own browser. We pass the sealed envelope along. We cannot open it.

How long we keep things

Where your information goes

We are in Canada. Our server runs on Cloudflare's network. When you create a party, a Cloudflare bot check called Turnstile runs in your browser to confirm a person is signing up. Cloudflare sees your browser and IP address for that check, and we get back only a yes or no. Stripe, Brevo and Meta process data in the European Union and the United States. Transfers out of the EEA and the UK rely on the European Commission's Standard Contractual Clauses, which those processors have in place.

Your rights

You can ask us to show you what we hold, correct it, delete it, or send it to you in a portable form. If you are in the EEA or the UK you can also object to processing or ask us to restrict it, and you can withdraw consent to email at any time.

One honest limit on the portability right: what we can hand over is the locked form, because that is what we have. The readable copy is produced by your own browser with your own password, and the builder's Save the party as a file button is how you take it with you.

Email # and we will answer within 30 days, at no charge.

If you are not satisfied you can complain to the Office of the Privacy Commissioner of Canada, or to your own supervisory authority in the EEA or the UK.

Security

The site is served over HTTPS. Sign in never sends your password: your browser derives a secret from it and sends a hash of that, which is what we compare against.

If somebody took everything on our server, they would have a list of email addresses, a set of password hashes, some payment references, and blocks of ciphertext they have no key for. There are two exceptions. Next to the email address of a checkout nobody has finished sit a child's first name and a party date, readable, until it is paid, stopped or the day passes. And a birthday reminder you asked for holds a name, an optional first name, an email address, a phone number and a birthday date, readable, until it is sent or stopped. No card numbers, no passwords, and no other readable party content. A Stripe payment reference names a payment that already happened; it is not a way to charge a card.

That is a real reduction in what a breach costs you. It is not a claim that nobody can ever open anything: a weak password is still a weak password, and the key is derived from it. If a breach ever did affect you, we would tell you and the relevant regulator without undue delay.

Changes

If we change this policy we will change the date at the top. If a change is significant and you have bought from us, we will email you about it rather than quietly editing the page.