Last updated: August 2026
This policy sets out how long SpotiQueue keeps different categories of data, and what triggers deletion. It's written for both internal use and public reference, so hosts and guests know what to expect.
We keep personal information for as long as it's needed to provide the service, meet a legal obligation, or resolve a dispute, and no longer. Most short-lived data (sign-in tokens, one-time codes) is deleted automatically. Longer-lived data (account details, queue history) is generally kept until a host or guest takes an action that removes it, such as deleting their account.
| Data category | Default retention | What ends it |
|---|---|---|
| Host account profile | Until account deletion | Account delete flow |
| Sessions (host) | Cookie/session expiry | Logout, revocation, deletion, or natural expiry |
| Email verification / account-delete tokens | 24 hours | Use, or expiry |
| Password reset tokens | 1 hour | Use, or expiry |
| Guest OAuth state, pending OAuth links, Spotify owner OAuth state | 15 minutes | One-time use, or expiry |
| Two-factor / passkey / password-reset challenges held in session | 10 minutes (30 minutes for initial TOTP setup) | Use, or expiry |
| Sent-email log | 7 days | Deleted automatically on a rolling basis |
| Guest cookies and guest sessions | 365 days | Natural expiry, or a host wiping guest data for their instance |
| Fingerprint records, queue attempts, votes, banned tracks | Until a host resets guest data for that instance, or the instance/account is deleted | Instance reset, instance delete, or account deletion (which cascades) |
Guest identity records (guest_identities) | Indefinite, no automatic expiry | Manual clean-up; related records are set to null rather than deleted when a linked account or instance is removed |
| Application logs | Set by our hosting arrangement, not by the application itself | Rotated or purged according to our infrastructure configuration |
| Plan waitlist email addresses | Until you're notified or ask to be removed | Manual removal |
| Dashboard feedback submissions (message, type, account email snapshot, status; linked account id) | Until a platform admin deletes the row | Admin delete in Feedback inbox; linked account id is cleared if that account is deleted |
| Pro support messages (Account → Support thread; user and admin replies) | Six months from each message's timestamp | Automatic daily purge; platform admin may delete individual messages sooner; thread row kept; account deletion removes the thread |
A note on guest identity records: because of how our database relationships are set up, deleting an account or instance doesn't currently cascade all the way through to a guest's linked identity record, those get disconnected rather than deleted. We're flagging this here rather than glossing over it, since it's a genuine gap between "your account is deleted" and "every trace of related guest activity is gone." If this matters to you, contact us and we'll action a manual clean-up.
Account deletion (hosts). You type a confirmation phrase, confirm through a link sent to your email, and, if you have two-factor authentication turned on, confirm that too. Once confirmed, your account is deleted, which cascades to delete the instances you own and the queue data tied to them, and ends all of your active sessions.
Instance deletion. A host can delete an individual queue instance. This cascades to delete that instance's configuration, banned tracks, queue history, votes, and pending queue entries.
Guest data reset. A host can wipe all guest activity for one instance without deleting the instance itself. This clears queue attempts, fingerprints, bans, votes, guest sessions, and pending queue entries for that instance. It doesn't remove the underlying guest identity record described above.
Unlinking connected accounts. Hosts and guests can unlink an OAuth provider where the interface supports it. Hosts always need to keep at least one working way to log in, so we won't let you unlink your last remaining method.
Application logs are written to standard output and captured by our hosting environment rather than a dedicated logging product. Known sensitive fields, such as passwords and authentication tokens, are redacted before anything is logged. Log retention is currently governed by our infrastructure setup rather than a fixed application-level rule; this section will be tightened up once that's finalised.
We review this policy whenever the product changes in a way that affects what we collect or how long we keep it, and at least once a year regardless.
Email [email protected] with questions about this policy, or to request that specific data be deleted outside of the normal automated schedule.
Questions? [email protected].
We use essential cookies to keep you signed in, run guest queues, and complete OAuth sign-in. We do not use advertising or third-party analytics cookies. Details are in our Privacy Policy.