Trust, without the sales call.

TuneLab has two request shapes — metadata lookups and audio uploads — and they touch completely different paths. Knowing which one your integration uses tells you exactly what we hold and for how long.

Metadata lookups (most calls)

GET /v1/analyze, /v1/key-bpm, /v1/resolve/{id}, and the Spotify compat shim never see your users' files. You send a track identifier (Spotify ID, ISRC, MusicBrainz ID, artist + title, etc.); we resolve against our pre-computed feature database (9.3M tracks indexed). On a cache hit the response is served from the Cloudflare edge in under 10 ms and nothing of yours is stored beyond the standard request log line.

Upload endpoints (when you compute on real audio)

POST /v1/bpm, /v1/key, /v1/lufs, /v1/key-bpm, /v1/beatgrid, and /v1/analyze/upload accept an audio payload. The byte path is:

1. Edge ingress — Cloudflare Worker (audio-features-api) authenticates the API key and forwards the bytes downstream. Workers do not write the payload to durable storage.
2. Compute — bytes go to our bare-metal FastAPI server (audion.s.tunelab.dev) for synchronous DSP, or to a Modal GPU worker for async jobs that need overflow capacity.
3. Async only — for async upload jobs, the audio is staged in a private Cloudflare R2 bucket (audio-features-uploads, prefix uploads/pending/*) so the GPU worker can pick it up.
4. Lifecycle delete — pending upload objects are removed by an R2 lifecycle rule after 1 hour. Generated stem outputs (vocal removal, separation) are removed after 24 hours.

What we do log

• Trace ID — random per-request ID propagated edge-to-Modal-to-bare-metal so you can ask support about a specific call without sharing the audio. Returned in the X-Trace-Id response header.
• Request metadata — endpoint, status code, latency, credits charged, API key prefix (tl_live_*), country (Cloudflare-derived).
• Cache key derivatives — for upload endpoints, a SHA-256 of the audio bytes is used as a cache lookup key so re-uploads of the same file are free. The hash is not reversible into audio.
• No payload bodies, no headers, no JSON content stored in logs.

TuneLab operates from the EU. Our bare-metal compute runs in Hetzner data centres in Germany (Falkenstein region). Our PostgreSQL feature database, our FastAPI compute servers, and our internal observability all live on the same private network in the same legal jurisdiction.

Edge traffic is handled by Cloudflare's global anycast network — your users hit the nearest Cloudflare PoP, the Worker authenticates the request, and any compute is routed back to the EU origin. Cache reads can be served from any region; compute and the durable feature database are EU-only.

Sub-processors

• Cloudflare, Inc. — edge network, Workers runtime, D1 cache, R2 object storage. Cloudflare GDPR posture.
• Hetzner Online GmbH — bare-metal hosting (Germany). Standard contractual clauses with us.
• Modal Labs, Inc. — on-demand GPU overflow for async jobs. US-based; engaged only when bare metal returns 503. [VERIFY: confirm Modal region pinning before promising EU-only async path]
• Stripe, Inc. — billing for the developer platform. Never sees end-user audio or analysis payloads.
• Resend — transactional email (magic link login for the developer dashboard). End users of your app are not in this system.

Data subject rights

Because TuneLab does not store end-user audio or end-user identifiers, the practical scope of data subject access requests is narrow: your developer-account email and billing data on the platform side. Email compliance@tunelab.dev for access, export, or deletion of your developer account data.

Certifications — honest status

• SOC 2 Type II — not yet certified. [VERIFY: confirm whether to publish a target date]
• ISO 27001 — not yet certified. [VERIFY: same]
• GDPR — operational compliance via EU-only compute, minimal data collection, processor DPA on request. We are not a "GDPR-certified" vendor (no such certification scheme exists in the regulation).
• Cloudflare and Hetzner upstream certifications (SOC 2, ISO 27001, ISO 27018, BSI C5) cover the infrastructure layer beneath us. Public reports linked from each vendor's trust page.

Most TuneLab requests never reach our origin: cache hits are served from Cloudflare's edge in single-digit milliseconds. Our exposed failure surface is the cache-miss path — bare metal FastAPI plus the Modal GPU overflow.

What we do during an incident

• Cache stays up. Even if bare metal and Modal both fall over, cached responses (the vast majority of traffic) keep flowing from Cloudflare D1.
• Backpressure, not blocking. The compute path uses an asyncio.Semaphore(10) with instant-503 on overflow. We fail fast so your retry logic stays in control.
• Modal overflow. A 503 from bare metal automatically routes the same request to a Modal GPU container. Bus factor on the bare-metal box alone does not take the API down.
• Public status page. status.tunelab.dev [VERIFY: confirm URL is live] — incidents are posted in real time, retroactive RCAs published within 5 business days.
• Trace ID in every response. Open a support ticket with the trace ID and we can answer "what happened to this exact call" — not "show us your logs."

A startup API replacing Spotify is exactly the kind of dependency a CTO is right to be paranoid about. We treat that paranoia as a feature requirement, not an objection to deflect.

Open spec, open shim

• Public OpenAPI spec. The full machine-readable contract is at /api/openapi.json. You can regenerate clients in any language any time.
• Spotify-compatible schema. /v1/compat/spotify/audio-features/{id} returns the exact JSON shape Spotify's deprecated endpoint did. If we vanish tomorrow, your parser already works against any other Spotify-shim provider.
• Public changelog with semver. developers.tunelab.dev/changelog. Minor versions add fields; breaking changes get a 90-day notice and a new /v2/ namespace. No silent deprecations.

Data export & portability

• Pull what you've computed. Anything we have analysed for you — your async job results, cached features tied to your account — is exportable as JSON or NDJSON via the platform dashboard.
• Stable identifiers. Our internal IDs are derived from MusicBrainz IDs, Spotify IDs, ISRCs, and AcoustID fingerprints — all open identifiers you can use to re-resolve against any other service.
• Source code escrow on Enterprise. Available on request for Enterprise contracts. [VERIFY: confirm legal structure for escrow]

Continuity commitments

• 90-day shutdown notice. If we ever wind the API down, you get at least 90 days of advance email notice and continued read-only access during that window.
• Data export on shutdown. On shutdown notice, every paid customer gets a one-time bulk export of all features computed against their key.
• Open methodology. Our DSP approaches are documented at /technology. You can rebuild the equivalent of our pipeline in-house using published academic methods if you ever need to.

Authentication & secrets

• API keys — tl_live_* and tl_test_* prefixes, generated and rotated from the developer dashboard. Test keys never bill and never reach bare metal.
• HMAC-signed webhooks — every developer webhook delivery is signed with a per-account secret you can rotate. Failed deliveries auto-disable after 5 consecutive failures and require a manual re-test.
• Stripe webhook idempotency — billing events are deduplicated via INSERT OR IGNORE on a dedicated stripe_webhook_events table. No double-charges from retried webhooks.
• Scoped service tokens — Worker-to-bare-metal calls use a dedicated BPM_SERVER_TOKEN that has no other privileges. Worker-to-Modal calls use a separate AFA_CALLBACK_SECRET.

Network & transport

• TLS 1.3 everywhere. Enforced by Cloudflare in front of every public surface.
• Private network for origin traffic. Bare metal talks to our PostgreSQL on Hetzner's private 10.x network — never over the public internet.
• HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy set on all HTML responses. Preloaded for the apex domain.

Isolation

• Product isolation. The Audio Features API has its own Cloudflare Worker, its own D1 namespace, its own R2 buckets, and its own Modal app — completely separate from the consumer site at tunelab.dev. A failure in one cannot cascade into the other.
• Test-key isolation. Test keys (tl_test_*) hit a mock-response handler in the Worker. They never reach bare metal, never spend credits, never touch the cache.
• Async job isolation. Each Modal GPU worker runs in an isolated container with no persistent state across requests.

What we publish

• Public changelog with every release. Security-relevant fixes are tagged.
• Vulnerability disclosure. Email compliance@tunelab.dev with the subject prefix [security]. We acknowledge within 1 business day. Coordinated disclosure window is 90 days from first contact.
• Penetration testing. [VERIFY: confirm whether to publish frequency or disclose under NDA only]

Most teams onboard themselves on the dashboard with a credit card and never talk to us. For the rest of you with a real procurement process, here is the menu.

Legal entity

TuneLab is operated by a registered EU sole-proprietor business (Polish JDG) for the launch phase. [VERIFY: confirm exact legal entity name and registration number to publish] A formal limited company is on the Q3 2026 roadmap. Invoices are issued accordingly.

Compliance, security, or DPA questions go to compliance@tunelab.dev. A human reads it. We aim to reply within 1 business day. We sign NDAs but do not require one to answer routine questions about retention, sub-processors, or data location.

Everything else — pricing, custom integrations, partnership inquiries — hello@tunelab.dev.