Privacy Policy
What we hold, who can see it, and how to get rid of it. In plain English, because a policy nobody reads protects nobody.
Last updated 9 October 2026 · Version 2.1
What have you got on me? For the competitions, a name and your scores: no email, no phone, no address, no date of birth. Any club can also keep a register here, and a register is people and how to reach them, so it may hold your contact details, your date of birth and a parent's details. A club plan adds your membership, what you have paid, and your court bookings, lessons and team places. All of that is your club's, not ours. Section 3 lists every field.
Who can see it? This season's tables, ladders and draws are your club's notice board: anyone with your club's address can read them, and your club can show them on another website with a widget. Search engines are told not to list them, earlier seasons need a sign-in, and your club can make the lot members only, which publishing a club website does. Contact details and dates of birth are for the people your club lets see them. Your club's data sits in a database of its own rather than a shared table, so there is no query that reaches it from another club. No trackers, no analytics about people, no ad network, nothing sold. Our suppliers do one job each, in section 7. If your club publishes a website, no member's name goes on it: section 13.
How do I get rid of it? Ask your club. They can act today and we cannot act for them: an owner removes you from the register in seconds, and can go further and wipe your name out of the club's history in one press while leaving the scores standing. Take a copy first, which is one click for the whole club or for one member. Section 10.
1. Who we are
Clayside runs box leagues, ladders, championships, court booking, coaching and membership for racket clubs: tennis, padel, squash, badminton and pickleball. It is a trading name of Agentu Ltd, registered in England and Wales.
- Company number: 16191406
- Registered office: 10 Campbell Crescent, East Grinstead, West Sussex, RH19 1JR, United Kingdom
- Contact: our contact page
This policy covers clayside.app, every club subdomain, the file host at files.clayside.app, and The Sheet at clayside.app/sheet/.
We have not appointed a Data Protection Officer. We are not required to, and pretending otherwise would just give you a title to write to instead of a person. Use the address above; it reaches someone who can act.
2. Who is responsible for what
Your club decides who goes in its league. We just run the software. For your own account and for signing up, we're the ones responsible.
Under UK GDPR this split has names, and it matters because it decides who you ask for what.
Your club is the controller for what is inside its club: the names, the results, the register, the money, the court diary, the coaching, and anything it publishes on a website of its own. We don't decide who is on your register or what goes in a box, and we open your club only to fix something, as section 11 below sets out. For that data we are the processor, acting on your club's instructions, set out in our Terms and in full in our Data processing terms, which are the Article 28 annex a committee can file.
If you're a player and you want your name changed or removed, ask your club first: they can do it in seconds and it's their decision. If they can't or won't, write to us anyway and we'll help.
We are the controller for the accounts of people who run clubs, for what is typed at /setup, for a report sent to us from inside the app, and for the research survey in section 14.
3. What we hold
Players are a name. Club admins are a name and an email address. Nobody has a password with us, because there are none.
Inside a club's competitions
| What | Why it's there |
|---|---|
| Player name | To show who's in the box and who played whom. Unless your club records more on its register (below), it is the only thing held about a player: no email, no phone number, no address, no date of birth, no membership number. |
| Results and fixtures | Scores, dates, who entered a result and who confirmed it. That last part is what makes a disputed score answerable. |
| A level | One number for how strong a player is, worked out from their results, with a figure beside it for how sure of it we are. The only other thing that feeds it is the first box the club put them in, which decides where it starts. Nobody types a level in. It suggests who you might play and decides nothing. Your club can hide it from players; anybody who can read the register reads it either way. |
| Arranging a match | Who suggested which dates to whom, which was agreed, and one optional line of up to 120 characters. By name, as a score is. No contact detail, and no field for one: arranging a match tells neither player how to reach the other. |
| Finding a game | A game somebody posted, who it was offered to, who took a place or said not for me, and the name of any guest put on it. Whether a member has said not to be asked. Where a member with no results yet answered the one question about their game, that answer: it only chooses who is asked, is never shown, and never becomes a level. Never emailed, and no contact detail: nobody asked learns who else was. |
| Clubhouse | The club's last fortnight of results, on Home. It is worked out from the results above whenever somebody opens it and is stored nowhere. A member can keep their own results off it, and that choice is held against their name. A parent signed in for their child can make the same choice for them. Who said well played, wow or good luck about which result, by name, kept for 21 days. Never emailed. |
| Admin accounts | A display name and an email address for the owner and the club's admins, so they can sign in and be invited. |
| Sign-in tokens | The one-way fingerprint of a sign-in code, never the code. |
| Notices and devices | What the bell has shown you. For a device told to send notifications, the address your browser gave us, which of the 12 kinds it wants, and what the browser calls itself so you can tell two devices apart. Both hang off your own record. |
| Admin activity log | Who changed what, and when. It's what lets a club answer "who moved that score?", so it records a name and sometimes a reason an admin typed. |
Your club's register, on every plan
Any club can keep a register of its members here, typed in by hand or imported from a spreadsheet. None of it is required: your club records what it chooses. Everything in it is your club's, recorded for your club's own purposes, and nothing here is ever used for anything of ours.
| What | Why it's there |
|---|---|
| The member record | Name, whether they are current, when they joined or left. This is the register. |
| Contact details | Email, phone, postal address and any note your club types, where your club chooses to record them. None is required. Behind a permission of their own, so somebody can keep the register without reading the club's contact list. On a competition plan only the owner holds that permission; on a club plan, the owner and whoever your club gives it to. |
| Date of birth | Where your club records one, behind the same permission. It tells a club a member's age, and it is the switch that closes doors for a child (section 12). |
| Gender | Male, female or other, where your club records it or the member gives it. Optional; blank is a normal answer. Used for your club's funding returns and for working out who plays what. Nothing in the competitions reads it: it puts nobody in a box, on a ladder or in a draw. |
| A parent or guardian | For a junior, a parent's or guardian's name, email and phone, behind the same permission. A guardian your club adds for a junior becomes a person on the register in their own right (section 12). |
| Tags | Whatever words your club files people under. Nothing in the leagues reads a tag. |
| Somebody asking to join through your club's link | The name, date of birth and email somebody typed into the link your club shares, which competitions they want to play, and for a child, the name of the parent whose email it is. The email is proved with a code before anything is kept. Deleted on the clock in section 9. |
| A member's own sign-in address | Only where they have answered a code sent to it. An address sitting in a register signs nobody in; the code coming back is what turns it into a way in. A member under 18 never holds one. Anybody who can see contact details can see it. |
| A member saying they have no email | So nobody asks them again. There is no address in it, because there is none to hold. |
| What somebody switched off | Which of the 12 kinds of message they have turned off, and whether an address has asked us to stop or has bounced. The second is a one-way hash of the address and never the address, so a list of people who told us to go away is not a mailing list in disguise. |
| A member import | The name of the file, how many rows it had, which column went to which field, and for each row which member it added or updated and which fields it wrote. The file is never stored, and nor is anything typed in it: what an import brings in lands on the register and nowhere else. A one-way hash of the column headings lets the next import from the same spreadsheet offer the same matching. |
| The club's activity log | Who added, edited, merged or archived a member, and on a club plan who collected. It records what moved and never what it said: a phone number change is logged as a phone number change, and the number is not in the log. |
If your club is on a club plan
A club plan adds the membership, its money, the court diary, lessons and teams. None of it exists in a club that is not on one, and all of it is your club's too.
| What | Why it's there |
|---|---|
| The membership | Which category each member is in for each membership year, and whether they have renewed. |
| Households | Who is on a family rate together, and who pays for them. |
| Subscriptions, payments and the tab | What each member was charged, what has been paid, what your club recorded when somebody sent a transfer, and the running account of every charge, payment, refund and adjustment. The club's own account of its own money. |
| A Direct Debit instruction | An identifier for the mandate at GoCardless and its status. We never see a bank account number or a sort code: your member types those on GoCardless's own page. |
| Court bookings | Who booked which court and when, who they were playing with, and what for. If a member brings a guest, the name they typed for that guest, who is a person who has never been near Clayside. |
| Lessons | Who teaches at your club, what they charge, who was taught, when, and what was paid. |
| Playing for the club | For a club that picks teams: who said they were free on a Saturday, who was picked, who was a reserve, and what they played. |
| Applications to join | What somebody typed into your club's joining form, which is a public form filled in by a person your club has not met. Deleted on the clock in section 9. |
A club on those plans can also publish a website, which holds and shows a further handful of things. They are in section 13.
When someone starts a league
The form at /setup asks for a club name, the web address you'd like, your email, and your name if you want to give it. Nothing is created at that point. We hold what you typed, send one email with a six-digit code in it, and make the league when you type the code back. A league is a database of its own, and we only make one for an address somebody has proved they can read. If the code is never used, what you typed is deleted within the hour and no league ever existed. No league is created until the code is used.
To stop one address opening an endless number of leagues we keep a one-way fingerprint of the signup email: sha256 of the address, never the address, and nothing that runs back into it. It only ever answers "how many leagues has this fingerprint made lately".
IP addresses, and what the platform records about itself
Four forms record an IP address. Starting a league, asking for that code again, the contact form, and "forgotten your club's address?" are open to anyone on the internet, so all four are rate limited, and a rate limit has to count something. One table, deleted after 7 days, joined to no club, account or person. None of them is a record that you visited. Three forms inside a club do the same job with a salted one-way hash instead of the address, which cannot be read back into one and can only be compared with itself.
One line per request: which club's address answered, the shape of the route, the status, how long it took and how much of the database it read. No IP address, no browser, no name, no member, nothing that says who asked. It is how we know the platform is up and whether a club is being served slowly. And an error when something breaks, bucketed by hour and by the shape of the fault, with the stack trace stripped before the record exists and the path folded to a shape (/members/:id), so an address, a token or a member's id cannot ride into it.
A handful of dates about the club: when your first season started and ended, when one went live, when the first score landed, when you started a second. They tell us whether the product is working, they decide nothing, and none of them says anything about an individual.
What we don't do at all
- No analytics about a person. No Google Analytics, no Plausible, no Meta pixel, no Segment, no session recording, no heatmaps, and not "anonymised" analytics either. The line per request above is the only per-request record and there is no person in it.
- No ad network, nothing targeted at anybody, no advert served from anywhere.
- No automated decision about you. A level is arithmetic about a person and it is not a decision: it changes nothing about your membership, your money, your access or your standing, so nothing here has a legal or similarly significant effect.
- Nothing sold, rented or shared. Not to anyone, at any price, including if we're doing badly.
- No third-party fonts or scripts on your club's app or its website, so a visit is not quietly announced to anyone else. On this site, three forms load Cloudflare's bot check (section 7): the signup form at /setup, the contact form and the research survey. Every other page loads nothing from anybody else.
4. Why we're allowed to hold it
Contract, and a legitimate interest in not being overrun by spam. We don't rely on consent, so there's no banner to dismiss.
| What | Lawful basis |
|---|---|
| Running a club's league; admin accounts and sign-in | Contract: we can't provide the thing without it. |
| Names, results and levels | Your club's basis, as controller. Usually legitimate interests in running its own competition, or contract with its members. |
| The IP addresses and hashes behind the open forms | Legitimate interests: keeping a form that's open to the internet from being abused. We looked at doing it without an IP, and there isn't a way that works. |
| The anti-bot check | Legitimate interests: keeping a club's names and results from being collected in bulk by a script, and our inbox usable. |
| One line per request, and an error record | Legitimate interests: knowing whether the service works. Neither holds anything about a person. |
| The activity log | Legitimate interests: a club seeing who changed a result. |
| Our mail to club owners about Clayside | Legitimate interests: telling the people who run a club about the software they run it on. You gave us the address setting the league up, and one click gets you off it. |
| Suggested times for a match | Legitimate interests: arranging the matches a league is made of. |
| Messages about a member's own play, and the morning digest to whoever runs the club | Your club's basis, as controller: usually legitimate interests. Each kind can be switched off by the person getting it (section 5). |
| A message the club sends everybody | Your club's basis, as controller. It goes to the bell, and to an inbox only where the member asked for that. At most two a week. |
| Notifications to a device that asked | Consent: you tapped Allow. Switching them off withdraws it and deletes the device's address. |
| The register, the subscriptions and the payment records | Your club's basis, as controller. Usually contract with its members, or legitimate interests in running the club. We hold it as processor and decide none of it. |
| A member's receipts, renewals and messages about their own Direct Debit | Contract, on your club's side of it. They reach the address the member proved, and for five of them failing that the one the club holds on file, or a parent's on a child's record. Section 5 says which, and what stops it. |
| An application to join, or somebody asking to play through a club's link | Your club's basis, as controller: steps at your request before a contract. Deleted on the clock in section 9. |
| The one message telling a member how to sign in | Your club's basis, as controller: usually legitimate interests in telling its members how to use what it has bought. It carries nothing that signs anybody in, never goes to anybody under 18, and one tap stops anything else reaching that address. |
| A report sent to us from inside the app | Legitimate interests, ours: answering somebody who asked us for help, and fixing what they found. |
| A name, role or photo on a club's website | Consent for a person's own email or phone, given in their own app. The rest is your club's basis as controller (section 13). |
| Accounting records for paid clubs | Legal obligation: UK company and tax law. |
5. What reaches you, and how to stop it
Nothing reaches an email address nobody has proved, apart from your club's own mail about money and one message telling you how to sign in. Everything else is a switch on your own screen.
A player who has never answered a code is emailed nothing about their play. Not a fixture, not a result, not a deadline, not a draw. A club cannot buy its way past that or ask us for an exception: an address in a register is a contact detail somebody typed, and it is not permission. That member gets the notice waiting on their own screen instead.
The exception is money, and it is the club's own money. A club that has just charged somebody has to be able to say so, so five messages go to the address your club holds on file even where nobody has proved it: your membership is confirmed, a receipt, a failed Direct Debit, a lapsed membership, and a note that somebody is not renewing. For a junior, all five go to the parent or guardian on the child's record, with the child named. Every one carries a link that stops anything else reaching that address, in one tap and with nothing to sign in to, because that reader has no account here to hold a switch.
And one message about signing in. Your club can send a member one message telling them how to sign in, to the address it holds, even where nobody has proved it. It carries nothing that signs anybody in, never goes to anybody under 18, and one tap stops anything else reaching that address. When your club sends it with its renewals, it also carries the member's name, what they owe for the year, whether a Direct Debit is set up, and the club's bank details for paying by transfer.
The switchboard
Everything a member is sent about their own play is one of 12 kinds, and each is a switch on their own screen, for email and for their phone separately. A score waiting on you is the one that cannot be switched off, because chasing it is what the app is for. A club's message to everybody is off for email until you ask for it. The rest are on, and off is a tap. Every message that belongs to one of those kinds carries a one-click unsubscribe, which your mail app offers as a button at the top.
A daily digest exists for the member who never turned notifications on: one morning email listing what is waiting. It is assembled line by line against the same switches, so somebody who has turned everything off has no lines left and gets no message at all.
Your phone. Tap Allow and your browser gives us an address for that device, held against your own record with what the browser calls itself. Every message is encrypted, so the service carrying it cannot read it. That is the push service your browser uses, such as Apple's, Google's, Mozilla's or Microsoft's. Turning notifications off, in the app or in your browser, ends it and deletes the address.
Asking us to stop. An unsubscribe, a bounce or a spam complaint puts a one-way hash of the address on a stop list, and nothing of the club's goes to it again. A sign-in code still does, because otherwise a mistaken press would lock somebody out of their own club for good, and answering that code clears the stop. Signing in is how you undo it yourself.
Who a reply reaches
A message about money is from your club, so pressing Reply reaches the club's owner at the address the club was set up with, which is a real person's inbox. Everything else answers to an address we watch, and we pass on what belongs to the club. If you run a club and would rather your own address were not on your members' receipts, tell us.
Mail from us rather than from your club
We email club owners and admins now and then about Clayside itself: a new feature, sometimes an offer. You're on that list because you confirmed your email setting a league up, so a stranger who mistypes an address never ends up on it. One click unsubscribes, and leaving doesn't touch your sign-in codes. Everything else from us is a sign-in code, an invite, a confirmation, or a notice we are contractually required to send you.
One morning email goes to the committee and is your club's rather than ours: a digest of the jobs only somebody running the club can settle, such as two players who cannot agree a score. It goes to whoever can act, and it is a switch like any other.
7. Who else sees it
Our suppliers, each doing one job. Nobody else, and never for their own purposes.
| Who | What they get | What for |
|---|---|---|
| Cloudflare | Everything: they host Clayside, store every club's database, hold its photos and documents, and carry your connection. | Hosting and storage, on our instructions and never for anything of their own. |
| Cloudflare Turnstile, and Cloudflare's bot check | Your IP address, on the signup form at /setup, the contact form at /contact, the research survey, and on the app and the API at a club's address. | Telling a person from a bot, so a script can't collect a club's names and results in bulk or fill our inbox. No tracking across sites and no profile of anybody. It usually happens invisibly. It does not run on a club's own website pages, on the file host, or on the demos. |
| Resend | The recipient's email address and the message. | Delivering sign-in codes, invites, confirmations, everything in section 5, and our occasional note to club owners. |
| The push service your browser uses, such as Apple's, Google's, Mozilla's or Microsoft's | An address for your device and a message they cannot read, because it is encrypted to your browser's own key. | Carrying a notification to a device that tapped Allow, and only until it is switched off. |
| GoCardless | The name, email and bank details of a club owner who sets up a paid plan, typed on GoCardless's own page so we never see the bank details. | Taking the Direct Debit for the plan your club pays us for. Only a club that chooses to pay goes near it. |
| GoCardless again, on your club's own account | The name, email and bank details of a member paying your club's subs. Typed on GoCardless's own page, never on ours and never seen by us. | Collecting your club's membership fees, on club plans only. This is a different relationship from the row above and the two never meet. The account is your club's, the money goes from your member to your club's bank, we are not in the middle of it and we take no percentage. For that collection GoCardless is your club's processor rather than ours. |
That's the complete list. We'll also hand data over if the law actually requires it (a court order, not a polite request), and if we ever sold the business the data would move with it, in which case we'd tell you first and this policy would still bind whoever took it on.
The sponsor slot on a league page. A paid plan lets a club name one sponsor there; a free league, a trial and the demos carry one of ours instead, named on the page, who pays us rather than the club. Either way it is typed text and an ordinary link out, not an advert served by anyone: nothing loads from the sponsor, no script of theirs runs, nobody is tracked across sites. We do not count clicks, because there is no redirect through us and no counter behind the link, so a sponsor asking how many people clicked gets the same answer you would.
Two buttons in the app send a message to us rather than to your club. "Ask about a plan" emails us the owner's name, address, club and note. Report a problem sends the club, the sender's role and plan, the screen they were on, what they picked it was about, what they typed, and any errors their browser had just recorded; we read their proved address as they press it so we can reply, and we email them a copy. It is the one thing in the product that moves a member's words out of their club's database and into ours.
8. Where it's stored
Clayside is built and run from the UK, by a UK company, under UK GDPR. Your club's data is in Cloudflare's D1 database service, its photos and documents in Cloudflare's R2 storage, both served from Cloudflare's network.
Your club's database is pinned to the EU, and so is the store its files sit in. We set a jurisdiction that Cloudflare enforces: not a preference for where it should go, but a constraint on where it is allowed to be. It binds the main copy and every read replica alike.
That's a promise we can keep because it isn't ours to break: the constraint is set once when your database is made and cannot be loosened afterwards, by us or by anyone at Cloudflare.
The honest exceptions, because a policy that only lists the good parts isn't one. Email leaves, and mail in transit is not covered by anything above. A photo is resized before it is stored, by Cloudflare, and that one step is not covered by the pin; only the resized copy is kept, inside it. The line per request does not take the pin, because Cloudflare's analytics store has no jurisdiction setting, which is one more reason there is nothing about a person in it. And our own list of clubs, which holds each club's name and its owner's email address, is older than the pin: it sits in western Europe because that is where it was placed, not because anything holds it there. And Cloudflare keeps our own error and performance lines for 7 days so we can fix faults. They name a club and never a person, and they are not covered by the pin.
Cloudflare and Resend are both US-headquartered, so where data does travel it's covered by the safeguards UK law requires: the UK Addendum to the EU Standard Contractual Clauses, under each supplier's data processing agreement, and both are certified under the UK–US Data Bridge.
A notification to your phone travels through the push service your browser uses, such as Apple's, Google's, Mozilla's or Microsoft's, and all four of those are US companies. Your browser chooses that service, not us. What it carries is an address for your device and a message it cannot read, because it is encrypted to your browser's own key.
9. How long we keep it
| What | How long |
|---|---|
| Your club's league, money, courts, lessons and team sheets | For the life of the club. Old seasons are the point, so we don't quietly age them out, and a cancelled booking is kept rather than deleted because who cancelled it is what a club answers a question with weeks later. |
| A club's register | Held until your club removes it, and removal takes effect at once. There is no clock and nothing ages a member out, which is deliberate: a member who lapses stays on the register, so rejoining next year is a renewal link rather than a fresh signup, and a club can still answer who was a member in 2024. |
| Club owner and admin email addresses | While the club is live. If it closes, deleted within 30 days, then gone, unless a legal or tax obligation means we have to keep a record longer. |
| The owner mailing list | Up to a year after you leave, in case you come back. One click unsubscribes you; an unsubscribe we keep on a do-not-contact list so we don't email you again. |
| A signup nobody confirmed | One hour, then it's deleted: what you typed, the address, and the hold on the web address you picked. No league is created until the code is used, so there is no database to delete and never was. A league that does exist is never deleted for going quiet. |
| A closed club | Deleted within 30 days of you asking, and asking means an email from the owner to hello@clayside.app. The days run from the day you asked rather than from whenever we get to it. Photos and documents go in the same sweep. Export first: once it's gone, it's gone. |
| IP addresses behind the four open forms | 7 days. The hashes inside a club go with the row or token they belong to. |
| The signup-email fingerprint | 2 years, which is the window the limit it enforces works over. |
| Sign-in codes and links | 15 minutes. Invites, 14 days. |
| One line per request | Aged out by Cloudflare on their own schedule. We set no period and cannot extend one. |
| An error record | 9 days. |
| Notices in the bell, and arranging a match | 60 days, and you can clear a notice sooner yourself. |
| A device's notification address | Until you switch notifications off, or until it stops answering. |
| What somebody switched off, and who asked us to stop | For the life of the club. A stop we forgot would be a stop we broke, and it is a hash of the address rather than the address. |
| Somebody asking to join, or applying to | 90 days after your club decides it, either way, then deleted. One somebody started and never finished goes 90 days after they started it. One still waiting on your committee is left alone, because emptying a committee's in-tray on a clock would be us making the decision. The code that proved an address goes within a day whatever happens. |
| A member's own sign-in address | Until they remove it, which they do themselves and which is never refused. It also goes the moment a date of birth is recorded that makes them a junior (section 12), with any live code. |
| A level | Worked out again whenever a result changes, so it is a fold rather than a record. Removing somebody removes it. |
| A club's website, photos and documents | For the life of the club. An unpublished page stays as a draft until deleted. A photo taken down has its file deleted in the same second; the row saying it existed stays, so the club's own trail is honest. |
| A member import | For the life of the club. It holds no names and no values, only which members an import touched and which fields it wrote, and removing a member removes their lines from it. |
| A report sent to us from inside the app | Kept. We never edit one and never delete one, because a record of what somebody told us is worthless if it can be tidied afterwards. If yours holds something you'd rather we didn't keep, ask. |
| Research survey answers | Until the findings are published and a year after. An address given for the findings goes at that point or sooner; the IP hash, 30 days. |
| The activity log | For the life of the club. A trail with holes in it isn't one, and it records what changed rather than the value, so it is not a second copy of anybody's contact details. |
| The record of us opening your club | Kept indefinitely, and it is the one row here about us rather than about you: who, which club, when, and how many changes they made. No member, no page, no value out of any row. A record of who reached your data is worth nothing with the inconvenient parts deleted out of it. |
| Accounting records | 6 years, as UK tax law requires. |
10. Your rights
You can see it, fix it, take it, or have it deleted. Ask through our contact page and we'll answer within 30 days. It's free.
Under UK GDPR you can ask us to show you what we hold, correct it, delete it, hand it over in a portable file, or restrict or object to what we do with it, including anything done on the basis of legitimate interests.
Do it yourself, faster
- Export the club: an owner downloads the whole thing, every player, result, season, member and payment, as one file. One click, no request form, no charge.
- Answer a member's request: an admin opens that person on the register and presses Download what we hold. That is a subject access request answered in about a minute.
- Correct a name: an admin edits it directly.
- Sign out everywhere: signing out ends the session on our side, not just in your browser.
Getting your name out of a club
Removing somebody from the register takes them off it and stops everything, and it leaves the results they played. That is right for most people and it is not erasure, so an owner can do a second thing.
Anonymise them. One press, owner only. What goes is everything that says who: the name, the whole detail row (date of birth, email, phone, address, guardian, the club's notes), the tags, their sign-in, the notices addressed to them, and anything they typed arranging a match. What stays is everything that says what happened: every score, booking, entry, membership and line on their tab, now hanging off a record with no person in it. The club's log records that it happened and never who it was. It cannot be undone, which is the point of it.
One thing deliberately survives: the name a member typed for a guest they brought to a court. That is a third party's data, and erasing one person is not a licence to erase another.
Honest caveat: a completed season with a hole in the middle isn't a record any more, and the other players in that box have an interest in an accurate one. So the scores stay, with nobody's name on them. If that isn't enough for you, write to us and say so.
Closing your club down
Email hello@clayside.app from the owner's address and say you want the club deleted. The database, the photos and the documents are all destroyed within 30 days of the day you asked. You'll get a reply from a person, not a form.
Take your export first. Once it's gone there is no copy, no backup and no undo. There is no delete button, on purpose: it would take every member's record and every season anybody played, in one tap, with nothing to undo it.
Where to ask
If your request is about a name inside a club, your club is the controller: ask them, because they can act today. We'll pass it on and support them if you'd rather come to us. If it's about your admin account or your signup, ask us directly. If you run a club and somebody has asked you, the guide walks through answering them.
11. How it's protected
- Each club gets its own separate database. Not a shared table with a club column in it. One club cannot query another's data, because there's no query that reaches it.
- There are no passwords. You sign in with a link or a six-digit code that expires in 15 minutes. We can't leak a password we never asked you for, and you can't reuse one here that you've used elsewhere.
- Sign-in secrets are stored hashed, never in plain text. A code guessed wrong five times invalidates itself.
- A club's files sit on an address of their own, which sets no cookie, runs no script and has no page, so nothing there can reach your sign-in.
- Everything is encrypted in transit (HTTPS, always) and at rest by Cloudflare.
- Access is limited to the people at Agentu who need it, and every time one of us opens a club it is recorded.
If something goes wrong anyway and it puts you at risk, we'll tell the ICO within 72 hours and tell you without undue delay. If you think you've found a security problem, please tell us: our security contact is here.
A limit worth knowing: the shareable link a club posts to its box's group chat is a key. Anyone who has the link can enter scores as anyone in that box. It's built that way on purpose (the alternative is forty accounts and forty forgotten passwords), but treat it like the key to the clubhouse, not a secret.
12. Juniors
Clayside isn't designed for children to sign up to on their own, and you must be 18 to run a club here. A club may well put junior members' names in a box league, and that's normal, but it's the club's decision as controller, under its own safeguarding arrangements. If you're a parent and you'd rather your child's name wasn't shown, ask the club; they can change it or remove it themselves.
The date of birth
Any club may record a date of birth on its register. On a club plan it often decides a membership category, because those are mostly age bands. For a child that date does one more job, and it is why we ask clubs to record it rather than leave it out: it is the switch that closes doors.
- A junior never holds a sign-in address. The route that adds one refuses a date of birth under the club's adult age, and refuses it again when the code is answered.
- A date of birth recorded later takes one away, whoever records it. A club filling a birthday in a month afterwards removes the address and any live code on the spot, and so does a member answering honestly on their own screen: somebody who turns out to be fifteen loses their own way in as they type it, which is the wall working rather than a fault.
- The date itself is behind a permission, with the contact details, so a committee member reading the membership numbers sees how many juniors there are rather than which members they are.
What a parent gets instead. A guardian on a child's record is a person on the register in their own right, on any plan, signs in with their own address, and acts for their children from their own screen: arranging matches, editing details, reading notices. Money about the child goes to them, with the child named. That is how a junior takes part without holding a way in of their own.
The consequence worth stating plainly: no recorded date of birth means the software treats somebody as an adult. Deleting a child's date of birth does not protect them, it switches the protection off, and that is why we keep it for as long as the club keeps the member. Our safeguarding page is the fuller version for a committee.
13. Your club's own website
On a club plan, your club can publish a website at its own address. It is meant to be found in search, so the rule is the strict one: no member's name goes on any page of it, with one exception your club and that person both have to choose.
These pages are public, and on a club plan we ask search engines to index them. A club with no site, a club on a trial and a club we have suspended are all told the opposite: Disallow: /, nothing indexed. Everything on a club's address that is not one of those pages, the whole app included, carries a header telling every search engine to stay out.
What never reaches a page
No member's name. Not a box table, not a ladder, not a draw, not a result, not a booking. All of those moved behind sign-in on the day this shipped. What a page shows about your club is a count, a date, a price, a court, or words your committee typed. The pages carry no script and no cookie and never read your sign-in: a signed-in member and a stranger get byte for byte the same page.
The exception, and it needs two yeses
A club can put a few people on a contact card: a name and a role it typed, so a visitor knows who to ask. Beside that it can show the club's own address for the job (membership@, or the phone in the clubhouse), which belongs to nobody and needs no permission.
To show that person's own email or phone instead, they have to agree in their own app. We read the answer fresh every time the page is drawn rather than copying the address into the site, so withdrawing takes effect on the next page load rather than the next time the club publishes. A safeguarding officer named on the page works the same way.
Photos and documents
Photos, a logo and documents such as a constitution or a coaching timetable sit on a file host of their own (files.clayside.app), which answers nothing but the files your club put there.
Every photo carries a tick saying consent was obtained, and a photo without it is never drawn, at the page rather than only at the upload form. Be clear about what that tick is: it is the person uploading saying they have permission, not the people in the picture giving it. Your club is the controller and getting that permission is your club's job. If you are in a photo and would rather not be, ask the club; they can take it down, and the file is deleted in the same second.
14. The box league research survey
If you answered our survey about how clubs run their box leagues: your answers are research, they are published only as totals, and answering puts you on no mailing list. We ask for no marketing consent on that form, deliberately.
In 2026 we are asking clubs across the UK how they run their internal competition, because as far as we can find nobody has ever published an answer. The form is at clayside.app/research/ and the findings will be published free, with no email required to read them.
What it collects. Your answers, every one but the first optional. Your club, county and role if you give them, clearly marked optional, used to weight the sample and to say how many clubs took part. An email address only if you tick the box asking for the findings, and the database itself will not accept one without that tick. And a one-way, shortened hash of your IP address, to stop the form being filled in a thousand times by a script, joined to nothing and erased after 30 days while your answers are kept.
Why we're allowed to. Legitimate interests for the answers: research into a subject nobody has published on, reported only in aggregate, and you can object at any time. Consent for the email address and for naming your club as a participant, which are two separate boxes, both unticked when you arrive, and we store which wording was on the screen when you ticked. Either can be withdrawn by emailing us.
What we don't do with it. We don't use survey answers to sell you anything and we add no respondent to any marketing list. There is no marketing opt-in on the form, on purpose: contacting people for genuine research is not direct marketing, and collecting details to market to them later is precisely what would make it so. We don't publish your club's name against its own answers either, only totals, proportions and anonymous quotes.
To see your answers, correct them or have them removed, ask through our contact page with the club name you gave.
15. Changes
If we change this policy we'll update the date at the top. If a change actually matters (a new supplier, a new kind of data), we'll email club owners rather than quietly reissuing the page and calling it notice.
Version 2.0 was a rewrite rather than an edit. The product grew a club website, a file host, a court diary, coaching, team selection and a switchboard for what reaches your inbox, and the policy had not caught up with any of it. Club owners were emailed about it. Version 2.1 corrects it: the register is on every plan rather than only the club plans, an import keeps no copy of the file, and the push services and the bot check are named in full. Neither version describes a new use of anybody's data: each describes what the software was already doing.
16. Contact and complaints
Use our contact page, or write to Agentu Ltd, 10 Campbell Crescent, East Grinstead, West Sussex, RH19 1JR.
If we get it wrong, please come to us first. We'd rather fix it. But you have the right to complain to the UK's data protection regulator at any point, and you don't need our permission or our blessing:
- Information Commissioner's Office: ico.org.uk/make-a-complaint · 0303 123 1113