When you upload a beat, the file is used exclusively to run the audio fingerprint pipeline. The moment the pipeline completes — whether it succeeds or fails — the file is deleted from disk inside a finally block that runs unconditionally.
Your audio is never stored, indexed, archived, or shared with any third party. We don't retain samples, analyze your music beyond the clearance pipeline, or keep copies of uploaded files.
finally block — it executes whether the pipeline succeeds, fails, or crashes mid-run.Every clearance request is permanently tied to your account at the database level. Every query for request data — including the status endpoint, the detail page, and the pipeline log — filters by your authenticated user ID, not just the request ID.
This means even if someone else knows or guesses your request ID, they cannot read your data. The ownership check happens at the SQL layer, not in application logic that could be bypassed.
The link sent in every clearance email is not a URL containing your request ID. It's a URL containing a UUID v4 token — a random, unguessable 128-bit identifier that maps to your request internally.
Every portal endpoint validates this token before returning any data or accepting any response. Tokens expire after 14 days and are marked consumed on first use — a rights holder cannot respond twice, and an expired link returns a 404, not a data leak.
Payment processing is handled entirely by Stripe. When you click to upgrade, you're redirected to a Stripe-hosted checkout page. Sampleton never receives, stores, or touches your card number, billing address, or any payment method detail.
After payment, Stripe sends a signed webhook event. Sampleton verifies the signature and checks that payment_status == "paid" before upgrading your account. A failed or pending payment will never grant you a higher plan.
Your Stripe customer ID is stored in our database after first checkout so future billing portal visits don't create duplicate accounts if you ever change your email address.
User authentication is handled by Clerk. Sampleton's database never stores passwords, hashed or otherwise. OAuth tokens, session data, and email addresses are all managed inside Clerk's infrastructure.
When you sign in, Clerk issues a session JWT signed with RS256. On every protected request, Sampleton verifies that JWT against Clerk's public signing keys — fetched from Clerk's JWKS endpoint and cached in memory. Only the JWT's sub field (your stable Clerk user ID) is stored in Sampleton's own database, as a foreign key.
Every response from Sampleton includes a standard set of security headers. HTTPS is enforced at the infrastructure level by Render. The Flask session key is stable across restarts — a rotating key would invalidate all sessions on every deploy.
| Header | Value | Purpose |
|---|---|---|
| X-Content-Type-Options | nosniff | Prevents MIME type sniffing attacks |
| X-Frame-Options | DENY | Blocks clickjacking via iframes |
| Referrer-Policy | strict-origin-when-cross-origin | Limits referrer data sent to third parties |
| Permissions-Policy | camera=(), microphone=(), geolocation=() | Disables browser APIs not needed by the app |
| Content-Security-Policy | Restricted to known origins | Limits which scripts, styles, and connections are allowed |
API endpoints are rate-limited by authenticated user ID — not IP address. This prevents shared networks (offices, universities, VPNs) from interfering with each other's quotas, and prevents a single user with multiple IPs from bypassing limits.
| Endpoint | Limit | Keyed by |
|---|---|---|
| POST /api/submit | 5 per hour | User ID |
| POST /api/waitlist | 10 per hour | IP address |
| All routes (default) | 60/hour · 200/day | User ID or IP |
A full security audit was conducted on the Sampleton codebase prior to launch, covering all five backend Python files. 33 findings were identified across four severity levels. All 7 Critical findings were resolved before any real user data was accepted. The remaining open items are tracked as hardening tasks.
If you have a security concern, found a bug, or want to know more about how a specific part of the system works — reach out directly.