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 LLC, an Arizona limited liability company ("Soundslot", "we"), 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, google sign-in for studio staff, and google calendar sync for a studio that connects it) — 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. For a studio that connects Google Calendar, its bookings written to that calendar: the room, the time and the customer's or band's name.
• 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.
• GitHub (theme files, for a studio that syncs its storefront theme with a repository) — The theme's own files, written to and read from the repository the studio connects. A theme carries layout and copy, and no customer's data.
• Slack or Discord (alerts to our own operators) — A studio's name when it signs up, starts, changes or cancels a plan, and the names of background jobs that failed, never a customer's data.
• 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, our servers report a booking to those accounts: the room, the amount, and the visit's own identifiers. A visitor who declined advertising is never reported, and where the studio asks first, only a visitor who agreed is. The customer's email address goes to Meta, hashed with SHA-256 before it leaves us, only where the visitor agreed to advertising. A phone number never does. These go to the studio's own accounts, under the studio's terms with Meta and Google.

Our own advertising. When somebody running a studio visits soundslot.app or signs up, we report the steps they take (an enquiry, a sign-up, starting checkout, starting a trial, a first payment) to our own Google Analytics and Google Ads accounts, with the visit's Google identifier and our own id for the studio. No name, email address or phone number goes with them, and nothing is reported for a visitor who declined cookies. A studio's customers are never reported to our accounts.

Google Calendar

A studio can connect a Google account so its calendars and Soundslot stay in step. That connection gives us Google user data, and this is all we do with it.

• What we read. The list of the account's calendars, and the free and busy times on the ones the studio maps to a room, a member of staff or a building. Where the studio turns on title rules, we also read the titles of events on the calendar it picks, so an event named after a room blocks that room.
• What we keep. Those busy times, and under title rules each event's title, as blocked time on the studio's own calendar. Nothing else from the account is stored.
• What we write. The studio's bookings, onto a calendar we create in that account or one the studio chooses: the room, the time, and the name of the customer or band.
• For how long. Busy times are replaced on every sync. Disconnecting the calendar in the console deletes every busy time it brought in and revokes our access at Google; revoking access from the Google account does the same from that side. Events we already wrote stay in the Google calendar until somebody deletes them there.

Soundslot's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. We use it only to keep the studio's calendar correct. It is never used for advertising, never sold, never used to train a model, and nobody reads it except to fix a problem the studio reports to us.

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.
• A walkthrough or checklist request from this site — 365 days. Long enough to follow up with a studio that asked. Deleted after that.
• 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. Our marketing site and the studio signup page also carry Google's analytics and advertising cookies, and where the law asks first, none is set until you agree. No storefront or checkout carries an advertising cookie of ours. 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.

Text-message opt-in data and consent are never shared with anyone. No mobile information is shared with third parties or affiliates for their marketing or promotional purposes.

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 and the sign-up steps reported to our own, both 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: hello@staging.soundslot.app. 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: hello@staging.soundslot.app. See also the terms of service and the cookie policy.