Privacy Policy — bookaLEAP B.V.

Effective Date: 01.07.2023 Last Updated: 14.10.2026 Version: 3.21

1. Introduction

At bookaLEAP B.V. (“bookaLEAP”, “we”, “us”, or “our”), we value your privacy and are committed to protecting your personal data. This Privacy Policy explains how we collect, use, share, and protect your information when you use our platform, apps, services, and website.

We comply with the General Data Protection Regulation (GDPR), the Dutch GDPR Implementation Act (UAVG), and other applicable privacy laws.

This Policy uses the same defined terms as our Terms and Conditions: “Leaper” for a user who books services (previously called “Client”) and “Expert” for an independent professional offering services (previously called “Partner”). “Expert” is an account-type label, not a certification or endorsement by bookaLEAP — see the Terms and Conditions, Sections 2 and 10.

2. Who We Are

bookaLEAP B.V. Jan Pieter Heijestraat 107H, 1053 GN, Amsterdam, Netherlands KvK: 89959973 — VAT: NL865165506B01 info@bookaleap.com

We act as a Data Controller for personal data collected through our platform and services.

3. What Personal Data We Collect

A. Account and Profile Information

• Phone number (verified by SMS code — this is how you sign in; we do not use passwords).
• Email address (verified by email code where provided).
• Full name, country, city, and time zone.
• Profile photo, cover photo, the free-text “about” description, and any social-media links (Instagram, TikTok, X, Facebook, or a website address) you add to your profile. You can add, change, or remove these at any time from your edit-profile screen.
• Date of birth and gender. Both are required when you register as a Leaper or as an Expert: registration cannot be completed without them. We ask for date of birth because you must be 18 to hold an account, and we check it against that threshold. Neither is shown on your profile, and neither can be changed from the app afterwards — write to info@bookaleap.com if one is wrong and we will correct it.
• Your sign-in identities: if you use Google or Apple sign-in, we store the provider and the account identifier the provider gives us, linked to your phone-verified account. If you sign in with Apple, we also store — encrypted — the sign-in token Apple issues to us for your Apple ID. We use it for one thing only: when your account is erased, we send it back to Apple so that bookaLEAP is removed from the apps connected to your Apple ID (section 10).
• Your acceptance of the Terms and Conditions (version and time) and your marketing preference.
• Referral code and, where applicable, who referred you.
• Last login time.

B. Expert and Business Verification Data

If you register as an Expert or a Business, we additionally collect the data we need to verify you and pay you:

• Legal name, business registration number and registering authority, registered address.
• For Experts: whether you are registered for VAT (BTW) and, where you are, your VAT (BTW) number.
• For Businesses: whether the organisation charges VAT (BTW) and, where it does, its VAT (BTW) number, because we issue the invoice for each sale in the Business’s own name and art. 35a Wet OB requires that invoice to identify the supplier. Each January we ask a Business to confirm its answer on whether it charges BTW, and record when it did.
• For a Business without a KvK registration: the legal name of its owner, printed on its invoices as the supplier (section 7, “Who is named on an invoice”).
• Bank details (IBAN, BIC) — stored encrypted — and, for a Business, the name of the account holder. A Business without a KvK registration that does not charge BTW may have its owner declare that its payouts go to the owner’s own account; we record that declaration, who made it and when.
• Tax identification for DAC7 reporting (section 3S).
• Certificates or qualification documents you upload.
• Verification (KYC) status and history.
• An optional public map location (latitude/longitude) that you explicitly choose to show on your public profile.
• For Experts: your registered address itself is never published or geocoded — only the map location above, which you choose to show, is.
• For Businesses, two addresses and only one is public. Your profile address is shown on your organisation’s public page and is geocoded to place the map pin there. Your registered address is your fiscal seat: we use it only on the invoices we issue in your name, and it is never published or geocoded. You may give us both, and they may differ. If you give no registered address, the invoice falls back to the profile one so that it still carries a supplier address.

C. Booking and Transaction Data

• Bookings, purchases (sessions, class packs / punch cards, combo offers, event tickets), payment status and amounts, promo-code usage, and remaining punch-card credits.
• Invoices and credit notes relating to your purchases.
• Where a payment for one of your bookings is reversed by your card issuer or bank (a “chargeback”), we keep a record of that reversal: the payment references involved, the reason the card scheme gave us, the amount, and the outcome.
• Payment card and bank details are collected directly by Stripe, our payment processor, and never touch bookaLEAP’s servers. We only receive confirmation of payment and a transaction reference.

D. Event Registration Answers

Event organizers may ask registration questions (for example about experience level or information relevant to participating safely). Your free-text answers are stored with your registration and shared with the organizer of that event. If you choose to include health-related information in an answer, see Section 5.

E. Content You Publish

Feed posts, comments to the extent the platform supports them, and images you upload (profile photos, post images) are stored and displayed as you direct.

If you report a feed post, we store which post you reported, that it was you who reported it, the reason you typed, and — once we decide — our decision, the reason for it, and who made it. Reporting the same post again stores nothing further, and you cannot report your own post or one published by an organization you help run. Reporting is how we meet our obligations to act on illegal and abusive content; we do not tell the author who reported them.

F. Communications and Forms

If you contact us through our public contact or event-hosting forms, we collect the name, email address, and message you submit.

G. Technical Data

• IP address — used for security and abuse prevention (rate limiting). The counter that limits how many sign-in codes can be requested from one connection stores only a one-way hash of the IP address, never the raw value, because it never needs to read it back.
• The counter that limits how many codes can be sent to one destination does hold the phone number or email address you entered, so that it can recognise the same destination again. It is written when a code is requested, including where the person requesting it never goes on to create an account.
• Device type, operating system, app version, and server logs.
• Address and map-location lookups: when you type an address into our location search, the query text is sent to our geocoding provider (Section 7) to return suggestions. When you place or drag a pin on a map to choose a location, the coordinates of that point are sent to the same provider to look up the address there.
• Map images: wherever the app or the website draws a map, your device fetches the map imagery directly from our map-tile provider (Section 7). That provider therefore sees your device’s IP address and which tiles it asked for — which is to say, the part of the world the map is showing you. We send it nothing about who you are, and it is a different provider from the geocoding one above.

H. Calendar Data (Experts)

If you connect your Google Calendar for availability sync, we store your Google account email and the access tokens Google issues — encrypted — and use them only for the sync you configured.

To work out when you are unavailable, we read the events in your selected calendar within the window we are checking. From each event we use only whether it is cancelled, whether it is marked “free” or “busy”, whether you declined it, and its start and end times. All we derive from this is a list of busy periods — the start and end times of blocks in which you are unavailable — which is held briefly in memory (up to one minute) and never written to our database. Event titles, descriptions, locations, attachments, and the identities of other attendees are never stored by us.

We also write events into that calendar for the bookings you receive, and update or remove those events when a booking changes or is cancelled. We only ever modify or delete events that bookaLEAP created; events you or anyone else created are never changed. The event we write carries the name of the service booked, the business name where there is one, the start and end times, the location, a link back to the booking, and the first name of the Leaper who booked you — so that your calendar tells you who you are seeing. We deliberately do not add the Leaper as an attendee, which keeps their email address out of Google. If you are a Leaper, this is how your first name can appear in an Expert’s Google Calendar when you book with them.

Our earlier ILU app syncs calendars differently — through Nylas, which receives whole events rather than only busy times (section 7). If you connected a calendar there, that is the integration you authorised; disconnecting it there ends it, and connecting on this platform gives you the narrower access above.

How we handle this data is further restricted by the Limited Use commitments in section 7.

I. Push Notification Registration (Mobile Apps)

If you allow push notifications in our mobile app, we store the notification token your device’s operating system issues, which platform it is (Android or iOS), and when we last saw it. The token identifies a device rather than you by name, but we keep it against your account so we can reach your devices, so we treat it as your personal data.

We keep at most the ten most recently used devices per account; registering an eleventh removes the least recently used one. If you never allow push notifications, we never hold a token for you and this section does not apply to you.

J. Reviews You Write

If you review an Expert who coached you or a Business whose venue hosted you, we store the rating you gave, any text you wrote, which booking earned you the right to write it, and when. The review is published: your first name and profile picture appear next to it on that Expert’s or Business’s public profile, which anyone can read without signing in. Your full name, phone number and email address are not shown.

A review is also personal data of the person it is about. Do not include anyone else’s personal data in the text.

If someone reports your review and we decide to hide it, we keep the report, our decision and the reason for it, and we send that reason to you.

K. Feedback You Send Us

If you send us feedback about the app, we store what you wrote, which account sent it, when, and — so that a bug report carries the build it came from — the platform and app version you sent it from. Feedback is a private channel to our team: unlike a review it is never published and no other user can see it.

Write what you like about the app itself, but please do not include other people’s personal data, and do not use it to raise a complaint about a specific person — that is what the report route on a review, and info@bookaleap.com, are for.

L. Direct Messages Between Users

The platform includes a private chat so you can arrange a booking without giving out your phone number or email address.

• We store the content of each message, who sent it, which conversation it belongs to, and when it was sent. Messages are private to the people in the conversation — they are never published, and no other user can read them.
• If you block someone, we store the fact that you blocked them so we can stop further messages between you.
• If you report a message, we store which message you reported, that it was you who reported it, the reason you wrote, and — once we decide — our decision, the reason for it, and when it was made. Reporting is how we meet our obligations to act on illegal and abusive content.
• Every message is checked automatically before it is sent. The check looks only for email addresses, phone numbers and links, and refuses to send a message containing one — it is how we keep a booking relationship on the platform. It is a pattern check and nothing more: no person sees it, nothing is recorded about what it found, nothing else in your messages is scanned, and it is not used to profile you.
• Beyond that check, we do not read your messages. Our staff read one when it is reported to us, when we are investigating abuse, fraud or a safety concern, or where the law requires it. We do not tell a sender that one of their messages was reported.
• If you have push notifications on, a new message sends one to your device. That notification carries the sender’s name and a short preview of the message, and it passes through the notification services in section 7 to reach your phone.

M. Your Acceptance of the Terms (and, for Experts and Businesses, of Self-Billing)

We record which version of the Terms and Conditions you accepted, and when. That is two fields on your account and nothing else — no IP address, no browser or app identification.

For an Expert or Business that same record does a second job. Because you are the seller of what you offer (Terms and Conditions, Section 4), bookaLEAP issues the invoice to your client in your name, and we may only do that with your prior agreement. Section 11 of the Terms is that agreement, so accepting the Terms is what authorises it and your acceptance record is the evidence of it. There is no separate self-billing acceptance and no separate record of one.

The record lives on your account, so the account rule in section 10 is what governs how long we keep it.

N. Tickets Bought for Someone Else (Guest Tickets)

When you buy tickets to an event for other people, you give us each guest’s name and email address, and you confirm that you may share them with us. We store them with your purchase, together with the guest’s seat, its check-in code and its status. If a guest’s email address already belongs to a bookaLEAP account, the ticket is added to that account instead, and we keep neither the name nor the email address you typed.

If someone bought you a ticket, we received your name and email address from the person who booked it. We use them to email you your ticket — the event, its date and time, a link to the event and a QR check-in code — and to tell you if that person cancels your ticket, if the event changes or is cancelled, and to remind you about a day before it starts. Our emails refer to the buyer only as “the person who booked your ticket”. Where the person who booked it has a bookaLEAP referral code, your ticket email also invites you to join bookaLEAP using that code.

The person who booked can correct your email address until the event starts — the ticket is then sent to the new address and the old check-in code stops working; the old address is not told — or cancel your ticket while cancellation is still possible, in which case we email you.

O. Feature Tiers and Feature Settings (Experts and Businesses)

Some features of bookaLEAP are switched on per Expert or per Business. To decide which ones you have, we may record:

• the feature tier we assigned to you — its name, and when we assigned it. Without an assignment you are on the standard tier, and we keep no record about you;
• a feature we switched on or off for you individually — which feature, whether it is on or off, when we set it, and the reason our team wrote down for doing so.

Our team sets these from our admin tools, and every change it makes is written to our internal audit log. A paid plan you buy (section 3P) also sets your tier, for as long as the plan runs. You see the result — which features you have — and, for a paid plan, the plan’s name, but not the reason our team recorded. A Business’s tier and feature settings are recorded the same way, against the Business. Leapers have no tier and no individual feature settings.

P. Paid Plans and Billing Details (Experts and Businesses)

If you buy a paid plan, or start a free trial of one, we record:

• the plan — which plan and price, monthly or yearly, its status, the trial and billing-period dates, and when it started, was cancelled and ended;
• who bought it, where the plan is for a Business — until that person’s account is erased;
• when you accepted the plan terms at purchase;
• whether you have used your free trial, because each Expert and each Business gets one;
• whether a payment for the plan was disputed with a card issuer;
• the reference of your customer record at Stripe.

Your billing details — business name, billing address, VAT number and email address — and your card are held by Stripe, our payment processor, not in our database. You enter the billing details in our app and we pass them to Stripe; we read them back from Stripe to show them to you. Stripe uses them to calculate the VAT on your plan and checks an EU VAT number against the EU’s VIES system. The invoices for your plan are issued and kept by Stripe on our behalf.

Q. Requests to Join a Private Community

A Business that runs a community can make it private: you then need its approval before you can book any of its events. If you ask to join a private community, we record:

• which community you asked to join, and when;
• what happened to the request — still pending, approved, declined, or withdrawn by you — and when it was decided;
• which of the community’s owners or admins decided it.

Each new request is a new record; an earlier request you withdrew, or that was declined, stays on your account as it was. If a request is approved, you become a member of the community, as you would by joining a public one. While a request is pending, the community’s owners and admins see it (section 7). If you run a private community, the record of a request you decided carries your account as the person who decided it.

R. How You Found Us (Booking Source — Website Only)

To learn which channels bring people to book — search engines, AI assistants, social media, other websites, our campaigns — our website notes how you arrived when you open the first page in a browser tab:

• the kind of source — search engine, AI assistant, social network, another website, a campaign link, or direct (no referring site);
• the referring site’s domain (for example www.google.com), never the full address of the page you came from;
• the bookaLEAP page you landed on, without anything after the ? in its address;
• campaign tags, if the link you followed carried them (utm_source, utm_medium, utm_campaign).

This note is kept in that browser tab’s session storage and disappears when you close the tab. Moving between our own pages does not change it. It only reaches us if you book from that tab — register for an event or a series, or buy an offer — in which case we store it with that booking. For a paid event checkout we store it with the payment for that checkout, which links to the registrations it creates. Our mobile apps do not collect it.

We use it only to count bookings per channel. We do not use it to profile you or decide what you see, and we do not share it with anyone.

S. Tax Identification for DAC7 Reporting (Experts and Businesses)

As a platform operator, bookaLEAP must collect identifying details about the sellers on the platform and report them, with what they earned through the platform, to the Dutch Tax and Customs Administration (Belastingdienst) each year under the EU’s DAC7 rules (Council Directive (EU) 2021/514, implemented in the Netherlands in the Wet op de internationale bijstandsverlening bij de heffing van belastingen). This applies to every seller, whether a business or a private person. We collect:

• From an Expert: your citizen service number (BSN), or, if you are not resident in the Netherlands, your tax identification number and the country that issued it. You give it in your payout details, and payouts are not possible without it.
• From a Business that is a legal entity (for example a BV, NV, foundation, association or cooperative): its legal form and its RSIN.
• From a Business that is not a legal entity — a community without a KvK registration, or a sole trader or partnership registered with the KvK: its legal form where it has a KvK registration, and, from the owner who declares for it, that owner’s BSN (or foreign tax identification number and country), date of birth and home address. That owner is reported as the seller for the sales made while they are the declaring owner. A Business cannot withdraw its balance until these details are given.
• For each payment, which seller it is reported under, fixed when the payment is made, so that a later change of owner or legal form does not move past sales to someone else.

How we hold it:

• Your BSN or tax identification number is stored encrypted and shown back to you, in the app and to our staff, only as its last three digits. The one place it is used in full is the DAC7 file we prepare for the Belastingdienst (section 7).
• Each year we give you a statement of what we will report about you for the previous year: your identifying details and, per quarter, what you earned, the fees we charged and the number of sales. We let you know in January when it is ready, and you can download it as a PDF from your earnings page. An Expert who set up payouts before we collected the BSN receives one request to add it.

The legal basis is our legal obligation to collect and report these details (art. 6(1)(c) GDPR). We process the BSN because that law requires it (art. 46 UAVG).

4. How We Use Your Data

5. Health-Related Information

We do not require health information and do not systematically collect it. Event registration questions or your communication with an Expert may invite information relevant to safe participation (for example injuries or conditions); providing it is optional and constitutes your explicit consent to process it for that booking. You can decline to share it, and you may ask us or the organizer to delete it at any time via info@bookaleap.com.

6. Marketing Communications

We only send marketing communications if you opt in — via the checkbox during registration or your profile settings. You can withdraw at any time via your profile settings or by contacting info@bookaleap.com.

Push notifications and SMS are not marketing. We use them only to tell you about your own bookings, events, purchases, invoices, payouts, and account — the same notices you already see in the app. You control push notifications through your device’s notification settings, and turning them off there stops them without affecting your in-app or email notifications.

7. Sharing Your Data

We only share your data with third parties where necessary to operate the platform:

• Stripe — payment processing (payment amounts, currency, and transaction references; your card/bank details go to Stripe directly). When you buy tickets for other people, the names and email addresses of your guests are attached to the payment, so their tickets can be issued once it succeeds (section 3N). For a paid plan (section 3P), Stripe also holds your customer record — business name, email address, billing address and VAT number — and your card; runs the subscription; calculates the VAT (Stripe Tax) and checks EU VAT numbers with VIES; issues and emails your invoices, renewal and payment reminders; and hosts the page where you update your card and see those invoices.
• Supabase — our database, authentication (SMS and email verification codes, Google/Apple sign-in), and file storage (uploaded images, invoice documents) provider.
• Google — if you sign in with Google, or if you are an Expert who connects Google Calendar sync. For calendar sync, Google receives the booking events we write into your calendar, which include the first name of the Leaper who booked you (section 3H).
• Nylas — calendar synchronisation for our earlier ILU app only, which is still running while we migrate people onto the bookaLEAP platform. Nylas receives Google Calendar data for users who connected a calendar in that app — event titles, times, attendees and updates — and uses it only to keep those calendars in step. It is not used by the bookaLEAP platform, whose calendar sync talks to Google directly and reads only busy periods (section 3H). This entry goes when the ILU app is retired.
• Google (Firebase Cloud Messaging) — delivery of push notifications to your mobile devices. Firebase receives your device notification token and the content of the notification, which can include your name, the title of a service or event, and when it starts. For a chat notification that content is the sender’s name and a short preview of the message (section 3L).
• Apple — if you sign in with Apple, including the request we send Apple to revoke that sign-in when your account is erased (section 10). On iPhones and iPads, push notifications also pass through Apple’s Push Notification service on their way to your device, carrying the same content described above.
• Twilio — sending SMS, used only to tell you that a session or event you are booked on starting within the next 24 hours has been cancelled.
• Resend — delivery of transactional emails (for example contact-form notifications, and the ticket emails we send to guests, section 3N).
• Photon (komoot) — geocoding: the address text you type into our location search, and the coordinates of a map pin you place, so we can return the matching addresses. Nothing else about you is sent with either lookup.
• OpenFreeMap — the map imagery itself. Every map you see in our apps or on our website is drawn from tiles your device downloads straight from OpenFreeMap, so it receives your IP address and the tiles requested, and nothing else — no account identifier, no search text, and no coordinates you have entered. It plays no part in geocoding, and we send it no data ourselves.
• Cloudflare — network security and content delivery in front of our services.
• Render and Vercel — hosting of our backend and web applications.
• Sentry — error monitoring for our servers and web app. When our servers fail to complete a request, or a page in our web app breaks, Sentry receives a technical report of the failure: the error message, the stack trace showing where in our code it happened, and context about the environment — the app or browser version, the operating system, the address of the page you were on, and our server’s hostname. We have switched off the setting that would attach your identity, your IP address, or the contents of your request, and we have asked Sentry not to store the IP address its servers see when your browser sends a report. Our admin panel, which only our own staff use, reports nothing to Sentry, and our mobile apps report crashes to Crashlytics instead (below). What can still reach Sentry is whatever our own error messages happen to say: they are written for engineers, and some name the record that failed — usually an internal reference number for an account or a booking, which means nothing outside our systems.
• Google Firebase Crashlytics — crash reporting for our Android and iOS apps, operated by Google. A crash report carries the error message, the stack trace, the app version, the operating system version, the device model, the device’s language and region setting, and its technical state at that moment: free memory and storage, and whether the app was in the foreground. It also carries two install-scoped identifiers Firebase generates so that reports from the same install can be grouped — a Crashlytics installation id and a Firebase installation id — which are stored on your device, are not linked to your account, and do not identify you to us. Separately from a crash, each launch of a release build fetches the SDK’s remote settings and sends a sampled session-start event carrying the same installation id, device model, operating system version, app version, and network type. We attach no user id, custom keys, or logs to either kind of report. As with any request your phone makes, Google’s servers see the address it connects from; unlike with Sentry, this is not a setting we control. Crashlytics is switched off in the developer (debug) builds we use internally, so it only ever reports on the app builds you install.
• Experts and event organizers — when you book with them, they receive your name, the booking details, and your registration answers. For a one-to-one session you book with an Expert, they also receive your profile photo. Contact happens through in-app chat, not by sharing your email address or phone number — Experts and event organizers never receive your contact details. For a ticket you bought for someone else (section 3N), the organizer sees the guest’s name next to yours on the attendee list and at check-in, never the guest’s email address.
• Owners and admins of a private community you ask to join (section 3Q) — while your request is pending, they see your name, your profile photo and when you sent it, so they can decide on it. The notification telling them a request is waiting does not name you. They never see your contact details, and other members of the community see nothing of your request.
• You, for the guests you booked — you can see each guest’s name and email address, and whether their ticket email was delivered, for the tickets you bought. Other attendees see neither.
• IndexNow — when a public page is published, changed or removed (a published event, an Expert or Business profile, an organization page, or one of our landing pages), we send its web address, and nothing else, to the IndexNow service. It shares that address with the search engines that take part in IndexNow, such as Microsoft Bing, so they can refresh it. These pages are already public; IndexNow receives no data about who views or books them.
• Authorities — where we are legally required to report. Under DAC7 we report each Expert and Business seller to the Belastingdienst once a year: the identifying details in section 3S, including the full BSN, RSIN or tax identification number, your bank account number (IBAN) and account holder name, and, per quarter, what you earned, the fees we charged you and the number of bookings (section 3S). This does not apply to Leapers.
• Our tax adviser — receives our year-end tax and accounting records, which list sales, invoices, payouts and balances per Expert and Business by name. It also receives the DAC7 file above so that it can prepare or check our report. It is bound by professional confidentiality.

All processors act under data processing agreements and only process your data per our instructions. We never sell or rent your personal data.

Who is named on an invoice

This is new, and it is worth reading if you are an Expert or a Business.

You are the seller, and we issue the invoice to your client in your name. Dutch VAT law requires an invoice to identify its supplier, so the invoice your client receives carries your legal or trading name, your registered address, and your BTW number — and the copy you receive carries your client’s name and, where we hold it, their billing details, for the same reason.

A Business without a KvK registration is invoiced under its name together with the legal name and postal address of its owner, because the owner who accepted the Terms for it is the supplier. The invoice carries the address you give as the registered address in its payout details, so the paragraph below applies to it too.

If you are a sole trader, your registered address may well be your home address. If you would rather it were not on documents your clients keep, use a business address for your registered details before you start selling — it is the address on your financial details that we print. Note that if you give us no registered address at all we fall back to your profile address (section 3B), so leaving the field empty does not keep an address off the invoice — it changes which one appears.

We have to do this: art. 35a Wet OB leaves us no discretion about what an invoice contains, which makes the disclosure a legal obligation (art. 6(1)(c) GDPR) rather than something you opt into. Section 11 of the Terms governs whether we may issue in your name at all, not what the invoice must say once we do.

What other users can see

Parts of your profile are visible to other people on the platform, so that everyone can recognise who they are training, booking, or attending an event with:

• Your Leaper profile — your name, profile photo, cover photo, free-text “about” description and any social-media links are visible to any signed-in user who opens your profile, whether or not you have booked with them.
• What your profile never shows — your phone number, email address, date of birth, gender, LEAP-coin balance, payment details, or booking history, whoever opens it. Some of this can still reach an Expert or organizer when you book with them; the sharing list above says what, and when.
• Expert and Business profiles are public-facing by design, since they exist to advertise offers and events. Together with organization pages and published events, they are public web pages: anyone can open them without signing in. Their text, photos, offers and upcoming events are part of the page as it is delivered, with a structured description for search engines, so search engines and AI search services that read the web can index and quote them. When one of these pages changes we tell search engines its address (see IndexNow above).

Because the “about” description is free text that other users can read, write only what you are comfortable sharing — in particular, you do not need to put health information there (see section 5). You can edit or clear it at any time in your profile settings, and the same applies to your social-media links: adding them is optional, and clearing a field removes that link from your profile.

Google Calendar data — Limited Use

bookaLEAP’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements. Concretely, that means:

• We use the data we receive from your Google Calendar only to provide and improve the availability-sync feature you switched on — the feature that reads when you are busy and puts your bookaLEAP bookings into your calendar.
• We do not transfer or sell that data to anyone, except as necessary to run that feature, to comply with applicable law, or as part of a merger or acquisition after giving you notice.
• We do not use that data for advertising of any kind, including personalised, retargeted, or interest-based advertising.
• We do not use that data for creditworthiness or lending purposes.
• We do not allow humans to read that data, unless you have given us your explicit consent to read specific events, it is necessary for security purposes such as investigating abuse, it is required to comply with applicable law, or the data has been aggregated and anonymised so that it can no longer be linked to you.

You can disconnect your Google Calendar at any time from Availability in Manage, in the app or on the web, or revoke bookaLEAP’s access from your Google Account permissions page. Disconnecting stops all further reading and writing; see section 10 for what happens to the data we already hold.

8. International Data Transfers

Some of our processors may process data outside the EU/EEA. In such cases we ensure adequate safeguards, such as Standard Contractual Clauses (SCCs) or transfers to countries with an EU adequacy decision.

Our Sentry organization is hosted in Sentry’s European region, so the error and crash reports described in section 7 stay in the EU and no transfer mechanism is required for them.

Crashlytics reports do not stay on that basis — Google processes them under the Google Cloud / Firebase Data Processing Terms, with the EU–US Data Privacy Framework and Standard Contractual Clauses as the transfer mechanism (Google Ireland Limited is the contracting entity for EU customers).

9. How We Protect Your Data

• HTTPS encryption for all traffic.
• Bank details (IBAN), BSNs and other tax identification numbers, calendar tokens and Apple sign-in tokens stored encrypted (AES-256).
• Phone-code and email-code sign-in — no passwords to leak.
• On mobile, session tokens are stored in the device’s secure storage (Android Keystore / iOS Keychain).
• Role-based admin access — our staff can see a guest’s name and email address to support that booking, and see a seller’s BSN or RSIN masked to its last digits; every admin action affecting your data is recorded in an audit log, including access to decrypted bank details and each download of the DAC7 file.
• Security counters (login throttling) store hashed identifiers rather than raw values.

10. Data Retention

We keep each kind of data only as long as the purpose behind it lasts. When you ask us to delete your account it is closed immediately — you are signed out and can no longer sign in — and we erase your personal data within one month. Erasure overwrites the data in place rather than removing your records; section 11 lists what survives it and why.

• Account and profile data: for as long as your account exists.
• Feature tier and individual feature settings (section 3O): until we change or remove them, and never longer than your account. Erasing your account deletes them outright, as well as those of any Business you are the active owner of.
• Paid plans (section 3P): the plan record for as long as your account, or the Business, exists; the invoices and payment records for it on the seven-year fiscal clock below. Your billing details at Stripe until you change them or your account is erased.
• Registrations you start but never finish: if you begin creating an account and stop partway, what you entered is kept so you can pick the wizard up where you left off — your phone number, the record that you accepted these terms, and whichever of email address, name, country, city, time zone, account type, referral code and marketing preference you had reached; if you started with Google or Apple, the identifier that provider gave us as well. We delete it 30 days after you last touched the registration. An email address on an unfinished registration also stops reserving that address after 7 days without activity: from that point a new registration using the same address takes it over. Until that happens the address stays with the unfinished registration and is deleted together with it at 30 days.
• Apple sign-in token (section 3A): for as long as your account exists. When your account is erased we send the token to Apple to revoke the sign-in, keep only a note of whether Apple confirmed it, and delete the token. A token from a sign-in that never becomes part of an account — a registration you never finish, or a sign-in you never link — is deleted after 30 days.
• Everything on the seven-year fiscal clock (art. 35a Wet OB): transaction data; every invoice, including those we issue in an Expert’s or Business’s name and the client details they carry; and the record of a reversed payment (section 3C), kept with the transaction it relates to.
• Which version of the Terms you accepted and when (section 3M): on the same fiscal basis (art. 52 AWR, art. 35a Wet OB) — for an Expert or Business this record is the evidence of their agreement to the self-billing those invoices depend on, so it is kept for as long as they must be.
• Marketing preference: until you withdraw it.
• Event registration answers: for the life of the registration and any legally required period.
• Guest tickets (section 3N): the guest’s name, email address and ticket are kept with the purchase they belong to, as part of its transaction data, and so are the ticket emails we sent them.
• Push notification tokens: for as long as the device stays registered. We delete a token when you sign out on that device, when the device stops being reachable, when it falls outside the ten most recently used devices on your account, or when your account is deleted.
• Reviews you write: published until you delete them or we hide them.
• Reports about a review, a message or a feed post, together with the moderation decision and its reason: for as long as we need them to handle complaints about that decision and to meet our Digital Services Act obligations.
• Requests to join a private community (section 3Q): for as long as your account exists. Erasing your account deletes them outright.
• Direct messages (section 3L): for as long as the conversation exists, so that both people in it keep their history.
• Feedback you send us about the app: while we work on what you raised and for as long as it stays useful to the product, then deleted. It is not published at any point. Deleting your account does not automatically remove feedback you have already sent; ask us at info@bookaleap.com if you want it removed as well.
• Google Calendar connection (section 3H): the access and refresh tokens are held only while the connection is active. When you disconnect, we revoke the refresh token with Google and erase both immediately; a record that the connection existed and was disconnected — your Google account email, the calendar identifier, and the relevant dates — is part of your account data and is erased with it. Busy periods read from your calendar are never stored.
• Security logs and hashed rate-limiting data: short rolling windows.
• Sign-in-code counters holding a phone number or email address (section 3G): no longer than the limit each one enforces, which lapses within hours of the code being requested, and any look into abuse of the sign-in flow.
• Error and crash reports (section 7): held by Sentry for the retention period of our plan, and by Crashlytics for the fixed period Google sets (currently 90 days), then deleted automatically.
• Tax identification and DAC7 records (section 3S): the BSN, RSIN or tax identification number, date of birth and home address, the seller recorded on each payment, and what we reported, for seven years after the end of the year they were reported for. This matches the Dutch tax record-keeping term (art. 52 AWR). If you never received a payment on the platform, your tax identification details are deleted when your account is erased.
• Booking source (section 3R): 13 months from the booking, then deleted automatically, or earlier when your account is erased. The note in your browser tab is gone as soon as you close the tab.

11. Your GDPR Rights

You have the right to access, correct, delete, restrict, and port your data, to object to processing (including marketing), and to withdraw consent at any time.

To delete your account, use Delete my account under Account & settings (the gear on your profile) in the app or on the web. You confirm by typing a short word, after which your account closes immediately and we erase your personal data within one month. We email you a confirmation when the request is received and again once the erasure is complete. If you signed in with Apple, the erasure also asks Apple to remove bookaLEAP from the apps connected to your Apple ID. Before you confirm, the app tells you if you still have upcoming bookings or a pending payout — we will not refuse the request because of them, but deleting does not cancel or settle them. If you are the sole owner of a Business, deleting your account also suspends it: its public profile and posts stop being visible, and its balance becomes unreachable until we reinstate it. There is no way to transfer ownership first, so consider that before you confirm. Deleting your account also cancels your paid plan, and that of any Business you own, immediately and without a refund for the rest of the period, and removes your name, email address, billing address and VAT number from our customer record at Stripe.

To get a copy of your data, use Download my data under Account & settings (the gear on your profile) in the app or on the web. We prepare a file and notify you when it is ready; the download link stays available for seven days, after which the file is deleted and you can request another. It covers your account and profile, bookings, purchases, payments, invoices and refunds, LEAP coin balance and ledger, reviews and feedback, chat conversations, the blocks and reports you made, your notifications, and — for an Expert — availability, offers, events and earnings records, the feature tier we assigned you, and any feature we switched on or off for you together with the reason we recorded (section 3O), and your paid plans and those of any Business you own (section 3P), your requests to join private communities (section 3Q), the booking source stored with each of your bookings (section 3R), and the tax identification details we hold for DAC7 reporting (section 3S), with the number shown as its last three digits only. If you own a Business, it also includes that organisation’s financial records, the same ones on its earnings page. The file includes a machine-readable copy you can take to another service and a readable summary of why we hold each kind of data and how long we keep it. Where a booking involves someone else, it shows their display name and the booking details, never their contact details. You can request an export twice a day. Your billing details for a paid plan are held at Stripe rather than in our database, so they are not in the file: they are shown on your plan page, and we send you a copy on request at info@bookaleap.com.

If someone bought you a ticket (section 3N), you have the same rights over the name and email address they gave us. You have no bookaLEAP account, so Download my data and Delete my account are not available to you: write to info@bookaleap.com from that email address instead.

To exercise any other right — correction, restriction, objection, or withdrawing consent — contact us at info@bookaleap.com. You can also use that address for deletion or access if you prefer. We respond to any request within one month. You may also lodge a complaint with the Dutch Data Protection Authority (Autoriteit Persoonsgegevens).

What deleting your account does not erase

Some data outlives an erasure request, because the law requires us to keep it or another obligation applies to it:

• Invoices and payment records — 7 years (art. 35a Wet OB, Dutch tax law). They stay linked to a pseudonymous account identifier, not to your name or contact details. An invoice we issued in an Expert’s or Business’s name, and the details of the client it was issued to, is a filed record and is not erased when either party deletes their account.
• Paid-plan invoices (section 3P) — on the same 7-year basis. Stripe keeps them for us, with the billing details printed on them when they were issued. A card you saved for a plan also stays on our customer record at Stripe, with the details you entered with it; to have it removed, write to info@bookaleap.com.
• Your acceptance of the Terms — kept on the same fiscal basis, because for an Expert or Business it is what authorises those invoices.
• Reviews you write — deleting your account anonymises them rather than removing them. The rating and text stay, so that an Expert’s or Business’s rating history is not rewritten by unrelated account closures, but nothing identifying you remains attached. This rests on our legitimate interest in an honest, stable public rating.
• Reports you made, and the moderation decision on them — the record stays, with the account behind it scrubbed.
• Tickets you bought for other people (section 3N). Each guest’s ticket, with the name and email address you gave for it, is part of the purchase record above and belongs to the guest’s own attendance, so deleting your account does not remove it.
• Direct messages you sent (section 3L). A conversation belongs to both people in it, so deleting your account does not delete it out of the other person’s thread — that would erase their own record of an exchange they took part in, and we rely on our legitimate interest in not doing that. The messages stay; the account behind them is scrubbed, so for a Leaper the thread shows “Deleted account” rather than your name. For an Expert or Business the name is retained on the DAC7 basis below, and so stays visible on the thread. If a specific message needs to go, write to info@bookaleap.com and we will look at it.
• Experts and Businesses only — DAC7 reporting. Where we have reported you as a platform seller to the tax authorities (see section 8), we must keep the identifying information behind that report. In practice your name is retained, together with the seller-identification details collected for it: for Experts, legal name, business registration number and authority, registered address, and VAT (BTW) number; for Businesses, the organisation’s legal form, RSIN and VAT (BTW) number. If you received at least one payment on the platform, your tax identification details in section 3S — BSN or tax identification number, date of birth and home address — are retained on the same basis for the period in section 10, even where you were the declaring owner of a Business rather than an Expert. Your email address, phone number, bank account number (IBAN), and all public profile content — description, public address and map location, and the date of birth and gender on your profile — are erased. This obligation does not apply to Leapers, whose data is erased in full.
• Error and crash reports already sent to Sentry or to Crashlytics (section 7). A report is a snapshot of the moment something broke, so it is not linked to your account and cannot be looked up by it; those reports expire on their own retention schedule rather than on your erasure request. To have a specific one removed, write to info@bookaleap.com.

If you are an Expert or Business, please read this before you delete: the retention above is not something we can waive, and it is the one part of your data that a deletion request will not remove.

12. Cookies & Tracking

We set no tracking cookies. Our web apps keep you signed in using browser local storage (session tokens), and Stripe may set cookies strictly for payment security and fraud prevention. Our error- and crash-monitoring providers (Sentry and Crashlytics, section 7) set no cookies and are not used to profile you. Sentry only reports technical failures, and only when one happens. Crashlytics additionally stores the two installation identifiers described in section 7 on your device and sends the launch-time settings and session telemetry described there, which we treat as necessary for the security and stability of the app.

Our website also keeps one measurement note in your browser tab’s session storage: how you arrived at the site (section 3R). It is first-party, it disappears when you close the tab, it is never shared with anyone, and it is used only to count bookings per channel. Because it only measures how well our own service reaches people and has little or no impact on your privacy, it falls under the exemption in article 11.7a(3)(c) of the Dutch Telecommunications Act and needs no consent.

We use no advertising or marketing cookies or SDKs and no third-party analytics, and we do not track your activity across other websites or apps.

If this changes — for example if we add any other analytics — we will update this section, request consent where required by law, and give you a way to accept or reject non-essential cookies.

13. Data Carried Over From ILU

bookaLEAP B.V. operated a booking platform under the name ILU, and that app is still running while we move everyone across. bookaLEAP is the same company, with the same registration (KvK 89959973) and the same responsibility as Data Controller; that data has not been sold, shared or transferred to anyone else. The two apps handle calendars differently (section 3H and the Nylas entry in section 7); everything else in this policy applies to both.

If you had an ILU account, we moved your records across so your history stays with you. What we carried over:

• Your name, email address and phone number.
• Your booking and event history, and any purchases or session credits still owed to you.
• Your LEAP Coin balance, where you had one.
• Your profile picture and, for Experts, your venue photos and description.

What we deliberately did not carry over:

• Your bank account number (IBAN). No payment details were migrated at all. Experts set up payouts again from scratch, by entering their bank details into the verification form in the app. We hold that IBAN ourselves, encrypted (section 9), and pay out from it by bank transfer — it is not held by Stripe, which we use only to take payments from Leapers.
• Your marketing preference. We could not verify what you originally agreed to, so we have set marketing email to off for everyone who came across. If you want to hear from us, turn it on in your profile settings — nothing is sent until you do.
• Your date of birth and gender. These were not migrated.

Your data is now held on the infrastructure and by the processors in section 7, which are not the same as ILU’s; the purposes in section 4 have not changed. Everything else in this policy applies to migrated data exactly as it does to data you give us directly, including your rights in section 11 and the retention periods in section 10. If you would rather we did not keep your ILU history at all, use Delete my account or contact us at info@bookaleap.com.

14. Changes to This Policy

We may update this Privacy Policy periodically. Material changes will be notified via email or app alert. Continued use of the platform implies acceptance of the updated policy.

15. Contact Us

bookaLEAP B.V. Jan Pieter Heijestraat 107H, 1053 GN, Amsterdam, Netherlands info@bookaleap.com