What we store, and what we don't do

Short version: we store the data needed to run bookings, we don't sell it, and card numbers never touch our servers.

Who holds your data

Soundslot is a US-based company that operates this platform. Which of us answers for your data depends on how you got here.

• You booked a room. The studio you booked with decides what it collects and why, so the studio is the controller of that data and we handle it on the studio's instructions. Ask the studio first; we will help either of you.
• You run a studio, or you visited this site. Then the data is ours to answer for: your staff account, your subscription, your support email, and the counters on these pages.

What we collect

• Account data — name, email, and a hashed password for studio staff and studio customers.
• Booking data — rooms, times, prices, gear requests, rentals, and booking history, so studios can run their calendar and customers can see their sessions.
• Phone number and text-message data — if you give a studio your number, we store it. If you opt in to texts, we also record that you consented, when, and on which screen (this is required by law), and — if you opt out by replying STOP or from your account — that you did so. See "Text messages" below.
• Payment records — amounts, payment status, deposits, gift-card balances, refunds, credit, and the processor's identifiers. This includes records of card holds (for example a rental damage deposit or an approval hold): the amount held, whether it was captured or released, and the identifier for it. Full card numbers go directly to the processor; we never see or store them.
• Studio integration credentials — a studio that sends its own texts gives us its messaging-provider (Twilio) credential. We store it encrypted at rest, never display it back in full, and never expose it in logs or errors.
• Operational logs — standard server logs and an audit trail of admin actions, kept for security and debugging.

Why we are allowed to hold it

• To do what you asked. A booking, a payment, a receipt, a reminder and a studio's subscription are all performance of a contract you entered.
• Because you said yes. Text messages and a studio's own advertising tags run on consent, recorded separately, and withdrawing it stops them.
• Because the law requires it. Payment and invoice records are kept for tax and anti-fraud rules, which is why they outlast an account.
• Our own legitimate interests. Keeping the service up, stopping abuse, counting page views in aggregate, and seeing which console features get used.

Where it lives, and who we share it with

Your data is stored in a database on infrastructure we operate, with encrypted connections and nightly off-site backups. To run the service we pass certain data to a small set of sub-processors, each for one purpose:

• Stripe (card payments, payouts to studios, and studio subscriptions) — Card details typed into Stripe's own hosted fields, plus the amounts, currencies and identifiers a booking, hold, refund or subscription needs. The billing contact for a studio's own subscription.
• Square (card payments and payouts, for a studio that takes money through square) — The same payment details and identifiers as Stripe, in its place. A studio uses one card processor or the other.
• Resend (email delivery) — The recipient's address and the content of the message: booking confirmations, reminders, receipts and account mail.
• Twilio (text messages, where a studio has switched them on) — The recipient's phone number and the text of the message. A studio brings its own Twilio account, and its messages are sent under it.
• Cloudflare (dns, certificates, the cdn, object and backup storage, bot checks and site analytics) — Every request to the site, including the address it came from. Encrypted database backups. A Turnstile challenge on the forms that carry one. The files a studio uploads and the ones we generate for it, held in Cloudflare R2 object storage: room and theme photos, receipts and invoices, and recording-project audio.
• Google (web fonts and maps on a studio's storefront, and google sign-in for studio staff) — From a visitor loading a storefront, the request for the theme's fonts, and for the studio's map where a page shows one, including the address it came from. From a member of staff who chooses Google sign-in, the name, email address and picture on that Google account.
• PostHog (product analytics for the studio console and the booking funnel) — Console usage events from a signed-in member of staff, and from our servers the marketing counters and five booking-funnel steps, keyed on a booking identifier or a salted daily digest.
• Sentry (error reporting) — Technical error reports with personal fields scrubbed and session replay switched off, so a card form is never recorded.
• Hostinger (the servers the application and the database run on) — Everything the platform stores, at rest on disks it operates.

Before anyone new joins that list we tell studios 30 days ahead by email, so a studio that objects can leave before the change takes effect.

Recipients a studio chooses. A studio can connect its own Meta and Google Analytics or Google Ads accounts. When it has, and only where the visitor agreed to advertising, our servers report a booking to those accounts: the room, the amount, and the visit's own identifiers. For Meta that includes the customer's email address and phone number, hashed with SHA-256 before they leave us. These go to the studio's own accounts, under the studio's terms with Meta and Google.

Where in the world

Our servers are in the United States, and every sub-processor above is either US-based or operates globally. If you book with a studio in the UK or the EU, your data reaches the United States. Each of those transfers relies on the receiving company's own approved transfer terms, which are the Standard Contractual Clauses or the UK addendum to them, and the same terms bind them to us. We can name the mechanism for any one of them on request.

How long we keep it

• A record of every email and text sent to you — 180 days. It answers what a studio told you and when. Deleted after that.
• The audit trail of what studio staff did in the console — 400 days. A card dispute can arrive most of a year later and this is what answers it.
• Webhook deliveries to a studio's own systems — 30 days. Useful for debugging a delivery, and of no use as history.
• Pre-deploy database snapshots. The seven most recent are kept, so a deploy can be undone. Older ones are deleted.
• Off-site encrypted backups — 30 days. The window a restore can reach back to.
• Bookings, payment records and the credit ledger. Kept for as long as the studio's account, because they are its financial records and ours. Erasing a customer clears the personal columns and leaves the money history behind, with no name on it.

Cookies

Sign-in cookies are what keeps you signed in, and no page of ours carries an advertising cookie. Every cookie on every surface, and which page sets it, is listed in the cookie policy.

Text messages

Text messaging is optional and off unless you opt in. A phone number on file is not consent on its own — we send texts only where you have separately agreed. If you opt out (reply STOP, or turn reminders off in your account), we stop and keep a record that you did. Opting out of texts never affects your bookings or email. Texts are delivered through Twilio.

What we never do

• We don't sell your data, and we share none with an advertiser except the booking reports a studio switches on for its own accounts, described above.
• We don't use customer lists for our own marketing — your customers belong to your studio.
• We don't store card numbers, ever.

Your rights

You can ask for a copy of what we hold, ask us to correct it, ask us to delete it, or object to a use of it. Studio customers can download everything a studio holds about them from the account page on that studio's site, and update their own details there. Staff and studio owners can do the same from the console.

Deletion is an erasure rather than a hole in the books. Every personal column is cleared, the saved card is removed at the processor, and the bookings and the credit ledger stay behind with no name on them, because they are financial records a studio has to keep. An upcoming booking is cancelled under the studio's policy first.

Ask the studio you booked with, or email us and we will act on it. We answer inside a month.

If you want to complain

Tell us first if you can: [email protected]. You also have the right to complain to a data-protection authority without asking us at all. In the UK that is the Information Commissioner's Office; in the EU it is the authority in the country you live in.

Contact

Privacy questions: [email protected]. See also the terms of service and the cookie policy.