What ClassLoop stores, and who can see it

What is stored

If you book a class

The participant’s name and the contact email address used to book. A phone number and a guardian’s name if the organisation asks for them. A short note if you leave one. Which sessions you booked, when, whether the place is confirmed or on a waiting list, and whether it was cancelled. Whether you attended, if the organisation marks attendance.

Not stored: a date of birth unless the organisation adds one to your record, a postal address, and any payment details at all — ClassLoop does not take payments.

If you run an organisation or teach

Your name, email address and a hash of your password. Never the password itself, and never in a log. Sessions on the devices you have signed in from, recorded as a keyed hash rather than the token itself, alongside the browser description and a one-way pseudonym of the network address — the address itself is not stored. Administrative actions you take, described below.

Your organisation’s own records

Classes, recurrence patterns, sessions, locations, rooms, teacher profiles, member records, bookings, attendance and the notes you write. These belong to your organisation and are visible only within it.

Who can see it

Within your organisation. An owner or administrator sees everything belonging to that organisation. A teacher sees only the sessions they are assigned to, the rosters for those sessions, the notes written for teachers, and each participant’s name, guardian name and contact number. A teacher cannot see your settings, your member directory, your reports, your internal notes, or another teacher’s classes.

That boundary is enforced by the database rather than by the interface. A teacher holds no direct read permission on any table; what they can see arrives through a small set of database functions that return only the permitted columns and re-check the assignment on every call.

Between organisations: nothing at all. Every record carries the organisation it belongs to, row-level policies compare that against the organisation the request is acting in, and the organisation a request may act in is derived from a verified membership on the server — never taken from a URL, a form field or a cookie on its own. There is no identifier a user could change to reach another organisation’s data.

Techvora. The tools we use to operate the service return organisation names, plan state, counts of classes, teachers, members and bookings, and when an organisation was last active. They are not able to return a member’s name or contact details, a booking, a register, or the contents of any note. That is a limit on what the tools can query, not a promise about what we choose to look at. Where a support request genuinely requires us to look at your records, we ask you first and the access is recorded.

A participant with a booking link. The private link in a confirmation shows that one booking and nothing else, and it can cancel it within the organisation’s cancellation window.

Analytics

Where usage analytics are enabled, they count anonymous events: a public timetable viewed, a booking started, a booking completed, a class created.

The following are never sent to an analytics service, under any configuration: participant names, email addresses, phone numbers, guardian names, class descriptions, teacher notes, administrative notes, attendance records, passwords and tokens.

The activity trail

Administrative actions are recorded so that an organisation can answer “who changed this?”: a class created or edited, a session cancelled, a teacher invited, a role changed, a booking altered by staff, attendance corrected, a setting changed, a sign-in and a failed sign-in attempt.

Page views, searches and filter changes are deliberately not recorded. A log of everything is a log nobody reads, and it turns an audit trail into a surveillance record of an organisation’s own staff. Passwords, tokens, contact details and the contents of notes are never written into it; each value recorded passes through a whitelist first.

Each organisation sees only its own activity. These records are deleted automatically after 400 days.

How long things are kept

• Classes, members, bookings and attendance: until your organisation deletes them.
• Activity and security records: 400 days, then deleted automatically.
• Sign-in sessions: 30 days, and removed shortly after they expire or are signed out.
• Password-reset links: 60 minutes, single use, then removed.
• Unaccepted staff invitations: 168 hours to accept, removed thirty days after expiry.
• Dismissed notices: sixty days.

Backups of the whole platform are retained on the database provider’s own schedule, so a deleted record may persist in a backup for a short period before those rotate.

Your rights, and how to use them

If you booked a class, ask the organisation you booked with — they hold your information and they can see, correct and delete it. Your booking link shows what is held about that booking.

If you run an organisation, inside ClassLoop you can:

• see every record you hold about a member on their own page;
• correct any of it;
• archive a member, which keeps their history and removes them from your working lists;
• delete a member’s record and their bookings outright;
• export members, rosters, attendance, bookings and reports as CSV.

If you need your whole organisation exported or deleted, ask and we will do it.

Security

Passwords are stored as bcrypt hashes. Session cookies are HTTP-only, marked secure over HTTPS, and namespaced to ClassLoop so a session cannot be shared with another Techvora product. Session tokens, reset links, invitations and booking links are stored only as keyed hashes, and the key lives in the server’s environment rather than the database — so a copy of the database alone cannot be used to produce a working link.

Sign-in attempts and reset requests are rate-limited. The database is reached only by a restricted role that cannot read any other Techvora product’s data, holds no ability to bypass row-level security, and cannot create an account or change a role by direct statement — those run through checked functions.

The forgotten-password page gives the same response whether or not an address is registered, so it cannot be used to discover who has an account.

Who else is involved

• Vercel — application hosting, served from the EU.
• Supabase — managed PostgreSQL, hosted in the EU (eu-west-1).
• Postmark — transactional email, where email is configured for the installation. It receives the recipient address and the message.

There are no advertising networks, no third-party trackers and no data brokers. The one webfont the site uses is served from our own domain rather than from a font provider, so loading a page does not tell anybody else you visited.

Classes for children

ClassLoop is used by organisations that teach children, and it is designed on the basis that an adult is doing the booking. It asks for the minimum a class place requires, has no feature that contacts a participant for any purpose other than their booking, and sends nothing that could be called marketing. An organisation is responsible for having whatever consent its own jurisdiction requires before it records information about a child.

Changes

If this notice changes in a way that affects what is stored or who can see it, organisations using ClassLoop will be told directly rather than by a silent edit to this page.

Contact

Privacy questions, export requests and deletion requests: support@techvora.net.