What Dapple does with your information.

Who is responsible for your information

Alistair MacLeod is the data controller for Dapple. He is a sole trader trading as Dapple Pet Care, of 3 St Pauls Court, York, YO26 4TP, United Kingdom. There is no company: Dapple is not incorporated, so any page or message naming a limited company as the operator of Dapple is wrong.

That covers the platform: your sign-in identity, your household record, your animals’ details, the requests you send, the bookings that follow, the payments Dapple takes, and the operational records Dapple keeps about all of it.

A care provider is a separate, independent business. Tamara’s Home & Hound is one such business and is the founding provider on Dapple; she is not Dapple and Dapple is not her. A provider may have data-protection responsibilities of their own for the care they give and for their own customers.

Where a provider’s work happens inside Dapple, how that responsibility is shared has not been settled, and this page will not pretend otherwise. The care record, the log a provider writes during a stay and a provider’s own customer records all sit in Dapple’s database, under rules Dapple wrote, for as long as Dapple keeps them — and they are also the working records of an independent business. Whether that makes the two of them jointly responsible, or responsible separately for different parts, is being settled with specialist advice. Until it is, Dapple is not handing that question to anybody else: ask Dapple about any of it and Dapple will deal with it, and work with the provider where the answer is partly theirs.

Write to [email protected] about anything on this page. It is Dapple’s own address, and it is no longer shared with the founding provider. Until the domain move it was her mailbox, because Dapple had no separate address in service; this page said so at the time, and says this now because it has changed. A privacy request sent there reaches the person responsible for it and nobody else.

What is collected when you ask for care

• Your name and email address.
• Your phone number and your postcode or area, if you choose to give them.
• Which service you are asking about, and the dates you have in mind.
• What you say about your animals, and anything else you add.
• Optionally, how you heard about Dapple or about a provider.

The request is stored so that it can be worked through: answered, checked against the diary, marked with where it has got to, and noted with an introductory visit if one is arranged. A copy is emailed to Dapple and a short acknowledgement is emailed back to you.

Your IP address and some basic browser information reach the spam check described below, and the limit on how often the form can be submitted. Neither is written into the database beside your request.

Please do not put alarm codes or key locations into that form. There is a proper place for them once a booking exists, described below, and they can be gone through at the introductory visit.

Asking for a particular provider, and how a request is placed

You can send a general request, or you can ask for one named provider. Those are two different records: what you asked for is kept as your own choice and is never overwritten by what happens next.

Neither of them gives a provider anything from your Dapple record. When Dapple places a request with a provider, that decision is recorded on Dapple’s side and Dapple contacts the provider itself. It gives that provider no access in the product to your request, your household, your animals, your address, your contact details or your animals’ records. What Dapple does release, and when, is the section after next.

That is about what Dapple releases, which is not the same as what a provider already knows. If you were a provider’s own customer before Dapple was involved — they invited you, or you have been booking with them for years — then they already had your name, your email address and your telephone number, and they may have written their own notes about you. Nothing about a booking, or the absence of one, changes that; it is their record of their own customer, and the next section but one says where it sits.

If you get an account

Dapple has no public sign-up. An account exists because somebody at Dapple made one after a request was accepted, or because you accepted a booking a provider offered you by invitation. From then on the following is stored:

• Your household — your name, phone number, a contact email if it differs from the one you sign in with, and the address where the care happens.
• Your animals — name, species, breed, age or date of birth, sex, whether they are neutered, your vet’s name and number, their feeding, exercise, toileting and sleeping routines, their medication, their behaviour and what they are like with people and other animals, and any health conditions or allergies you record.
• Your emergency arrangements — an emergency contact, who may authorise veterinary treatment and up to what cost.
• Your bookings — the service, the dates and times, the agreed price and deposit, which provider is doing the work, and where the booking has got to.
• What is agreed for each stay — getting in, what to do if something goes wrong, how you would like to hear from the provider, anything about the house, and anything true only of that stay for a particular animal. This is where key and alarm details belong. Each change is kept as a new version, so the record of what was agreed, and when, is not overwritten.
• The stay log — what the provider writes while the stay is happening. Some of those entries are shared with you and some are the provider’s own working notes.
• Your payments — the amount, whether it is a deposit or a balance, when it is due, whether it has been paid, any refund, and the reference numbers Stripe uses.

Records kept about you that are not shown to you

Some records exist for Dapple to run the service and are not displayed anywhere in your account. They are named here because they are still information about you and your rights below still apply to them.

• A working note about your household, written by Dapple staff.
• A note against a request, written by Dapple staff when a request is placed with a provider, saying what was decided and why. These are added to and never edited or removed.
• A provider’s own notes about you, if you are one of that provider’s own customers. They are that business’s working notes, and they are held in Dapple’s database.
• An activity log of what happened to your request, your bookings and your account: the action, who did it and when. It does not copy your care details into itself, and it is added to and never edited or removed.

Not being on a screen is not the same as being out of reach. If you ask for a copy of what is held about you, these are searched with everything else.

When Dapple releases any of it to a care provider

This is about the account, household, animal and stay records described above — the ones Dapple holds because you put them there. Access opens in steps, and the step is decided by the state of the booking, not by who somebody is and not by anybody at Dapple deciding to open it.

• Before there is a booking: nothing. A provider who has been asked for by name, or who Dapple has spoken to about your request, is given no access at all to any of it.
• A draft booking: your name, the service, the dates, the price and how many animals. No address, no telephone number, no email address, no care notes and nothing from your animals’ records.
• A confirmed booking, and afterwards: your telephone number and contact email, the address, your emergency contact, who may authorise veterinary treatment, the access notes, the emergency plan and the care notes for that stay. This is the point at which the house stops being private, and it stays available while the stay is in progress and after it is finished, so that a past stay still makes sense.
• A cancelled booking: the sensitive half closes again.

A provider only ever reaches their own work. There is no screen and no route by which one provider can see another provider’s bookings, customers or animals. Dapple staff have their own separate access for running the platform, and being staff does not make somebody a provider or give them a provider’s access to a home.

If you are a provider’s own customer

A provider on Dapple may keep a record of their own customers — people who were already theirs, or who they invited. It holds a name, an email address, a telephone number and their own notes, and it exists so that they can offer you a booking and run their own business.

Those details did not come from your Dapple record. The provider types them in, because they are the ones who know them. So a provider can have your contact details, and can get in touch, without any booking existing and without Dapple having released anything.

There is one way round: a provider can turn an existing Dapple household into one of their own customer records, which copies across the sign-in address and telephone number. That is allowed only where they have had a booking with you that you actually confirmed at some point — a draft nobody agreed to is not enough, and neither is a request. Somebody you have never agreed to work with cannot reach your details this way.

The record sits in Dapple’s database and is the provider’s working record of their own customer. Which of the two of them answers for what is part of the question described at the top of this page, and until that is settled you can ask Dapple.

Why it is used, and on what legal basis

Your request is used to answer it, to say whether the dates are free and to arrange an introductory visit. Under UK GDPR the lawful basis is Article 6(1)(b) — taking steps at your request before entering into a contract.

After that, Article 6(1)(b) covers what Dapple’s own agreement with you needs in order to work: your account, administering the booking, holding what you write about your animals and the arrangements for a stay, releasing it to the provider at the point the booking is confirmed, and taking the payment. That is the platform’s contract with you, and not the provider’s. Where a provider then uses the same information to carry out the care they agreed with you, that is their own processing under their own agreement, and how the two fit together is part of the question described at the top of this page.

Placing a request with a provider, keeping the operational notes described above, keeping the activity log, the spam check and the limits on how often a form can be submitted all rely on legitimate interests under Article 6(1)(f): running a working service, keeping a record of who did what, and keeping the forms usable. Keeping payment and accounting records is a legal obligation under Article 6(1)(c).

Some of what you write about an animal is health information. It is about your animal and not about you, so it is not special category data about a person; what is asked for is what somebody looking after them has to do, and not a clinical history. Your own emergency contact and the person you nominate to authorise treatment are ordinary contact details about a person, and are collected because a decision about an animal should never have to be made from an airport.

Who else handles it

• Supabase holds the database everything is stored in and runs the sign-in system behind your account — your sign-in address, your sessions and the sign-in links it writes. The project is hosted in Ireland. Supabase acts on Dapple’s instructions as a processor.
• Cloudflare sits in front of this website and supplies the Turnstile check on the request forms, which uses your IP address and browser information to tell a person from a bot.
• Resend delivers the email: the request to Dapple, the acknowledgement to you, booking and payment messages, and the sign-in links.
• Stripe handles card payments and provider payouts. Stripe is not only a processor: as well as processing payments on Dapple’s instructions, Stripe uses payment and device information for its own purposes, including preventing fraud, meeting its own regulatory obligations and running its payment service. Stripe describes those purposes in its own privacy policy at stripe.com/privacy.
• OVHcloud hosts the server that runs this website, in a data centre in London, United Kingdom. It is deployed there with Coolify, which is deployment software and not a separate hosting company.

If a Google or Facebook sign-in button is shown on the sign-in page, using it tells that provider you are signing in here, and tells this website the email address on your account with them. It creates no account and gives them nothing else about you. The email sign-in link works the same way for the same account and is always available.

Supabase, Cloudflare, Resend and OVHcloud act on Dapple’s instructions under a contract. Some of them, and some of the companies they in turn use, are based outside the United Kingdom.

UK data protection law requires an appropriate safeguard where information goes outside the UK and the destination has not been recognised as offering adequate protection. Each of these companies publishes terms describing the safeguards it offers for that. Which of those is the one actually in force for this deployment is being confirmed against the signed agreements, so this page does not yet name one, and does not claim a particular transfer is covered by a particular mechanism until it can. Ask and you will be told where that has got to for a particular service, and how to get a copy of the terms that apply.

Payments, and what is and is not held here

Dapple takes the payment and the care provider is paid from it. That is why a card statement reads Dapple Pet Care and the provider’s own name appears beside the booking instead.

The card form on the payment page is Stripe’s own. Your card details are entered into it and go to Stripe directly, and no part of a card number, expiry date or security code reaches this website or is stored in its database.

What is stored here is the amount, whether it is a deposit, a balance or the whole price, when it is due, whether it has been paid, when it was paid, any refund or dispute, the reference numbers Stripe uses to identify the payment, and — if a payment fails — the reason Stripe gives for the failure. The record kept of a message from Stripe is a deliberately narrow one: which event, of what type, about which payment, and what it said about how much money. The card details, billing address and cardholder name that Stripe’s own message can carry are not written down.

Bank details work the same way. A provider’s bank account is added inside Stripe’s own component and Dapple is never told the account number, the sort code or the account holder’s name; what it reads is whether a payout has somewhere to go.

Cookies, and what is kept in your browser

Dapple runs no analytics, no advertising and no marketing pixels of any kind. There is no Google Analytics, no tag manager, no social pixel and no tracking product of any sort in this website’s code. Nothing is shared with an advertising network and no information about you is sold to anyone.

On the public pages nothing is stored in your browser that needs your consent, which is why there is no cookie banner. Of the pages anybody can reach without signing in, the request forms are the only ones that load code from another company, and that is the Turnstile check. Behind sign-in, the payment page and the money pages a care provider or Dapple staff use load Stripe. All of it is described below.

Signing in sets a session cookie. It is what keeps you signed in as you move between pages, it is closed to JavaScript in the browser, and signing out clears it. Two other small cookies remember what you were doing when you were asked to sign in, and one remembers that you have dismissed a notice. A page only Dapple staff can reach also remembers, in the browser, that an install prompt was dismissed. All of them are strictly necessary for what you asked the site to do.

The Turnstile check from Cloudflare loads on the request forms and keeps some information in your browser in order to tell a person from a bot. Preventing and detecting fraud is one of the purposes the cookie rules name as not needing consent, which is why it does not ask you for any.

Stripe’s payment code loads on the payment page, and on the money pages a care provider or Dapple staff use. All of those are behind sign-in and none of them is a public page. Stripe stores its own information in your browser there and sends signals about your device and how you use the page to its own servers; Stripe states that it uses this for fraud detection and security, that it is never used for advertising, and that it may also load a hCaptcha check on the same page. It is Stripe’s storage, set for Stripe’s purposes, and it is described in Stripe’s own cookie policy.

That check has now been done, item by item, on the real payment page. This is everything it found, alongside the sign-in cookie described above.

• Opening the page sets one cookie for the captcha, which lasts about half an hour, and puts four short entries in the browser’s per-tab storage inside Stripe’s own frame. Those four go when you close the tab.
• Paying adds three cookies: __stripe_mid, which lasts about a year; __stripe_sid, which lasts about half an hour; and one called m set by Stripe itself, which lasts about thirteen months.
• Nothing is put in the two kinds of browser storage that would outlive all of that — there is no local storage entry and no database created in your browser, on any of those pages.

So two of those cookies are long-lived, and this page is not going to describe them as if they were not. Stripe identifies __stripe_mid, __stripe_sid and m as cookies it uses to prevent fraud, and says the signals they carry are not used for advertising.

There is no consent control on that page, and for the storage described above none is required. Preventing and detecting fraud, and keeping a payment secure, are among the purposes the cookie rules treat as strictly necessary, and that is what every item found there is for. This conclusion is about what was actually measured, on those pages, for those purposes — it is not a general permission.

If any of it starts being used for something else, or something new appears, that has to be looked at again before it is set — and your consent asked for unless one of the exceptions in the cookie rules genuinely covers it. Advertising, and following you between sites or devices, are the kind of purpose that needs asking. Some measurement of how the site is used can fall under a separate exception instead, which is why it gets judged rather than assumed either way.

How long it is kept

Nothing here deletes itself on a timer, and saying so is better than promising a schedule the software does not keep.

• Your account, household, animals, bookings and care records stay while there is a reason to keep them: so that your animals can be looked after the way they are used to next time, and so that a past stay still makes sense when somebody looks back at it.
• Payment records are kept as long as tax and accounting rules require.
• The activity log, the notes against a request and the stay log are added to and not edited. A stay entry can be withdrawn from view, which marks it as withdrawn instead of erasing it. That is deliberate: a record that can be quietly rewritten is not a record.
• Archiving an animal puts them away without erasing them, because past stays refer to them and would stop making sense otherwise.

There is no button that deletes your account and everything in it, and this page will not pretend otherwise. If you want something removed, ask. Anything there is no obligation to keep is deleted by hand, and you are told when it is done. Where something has to stay — a payment record, or a ledger entry that another record depends on — you are told that too, and why.

Your rights

You can ask for a copy of what is held about you, ask for it to be corrected, ask for it to be deleted, ask for its use to be restricted, object to its use, or ask for it in a portable form. Some of it you can change yourself at any time from your account. Email [email protected] and anything else is dealt with within one month.

A request for a copy covers the internal records named above as well as the ones you can see, and it is answered by Dapple. It also covers the care record, the stay log and a provider’s own customer record where those sit in Dapple’s database — Dapple will not send you away because the answer is partly a provider’s. Where something is genuinely the provider’s own, held outside Dapple, Dapple will say so and tell you who to ask.

If you are unhappy with how your information has been handled you can complain to the Information Commissioner’s Office at ico.org.uk/make-a-complaint, or on 0303 123 1113. Telling Dapple first means it can be put right sooner.