What we store. What we don't.

Audio data

Audio uploaded to /analyze is never kept. Files arrive over TLS, are held in a short-lived temporary file only while they are decoded and analysed on our server by Essentia and librosa, and that file is deleted as soon as processing finishes. No copy, no archive.

The result of each analysis is cached server-side, keyed by the SHA-256 hash of the bytes you sent. This means two users uploading the same file each get an instant cached response — but the cache stores only the analysis output (BPM, key, energy, etc.), never the audio.

Catalog data

The catalog is built from public sources only:

• Public catalogue sources — public chart and catalogue feeds, and 30-second public preview clips
• MusicBrainz — open music encyclopedia (CC0 metadata)
• AcousticBrainz — frozen July-2022 dump (CC0 audio descriptors)

Audio analysis uses publicly available 30-second preview clips only — we never download full-length tracks from streaming services.

Customer data we hold

• Account label — the email or company name you provided at signup
• API key — only stored as SHA-256(key); the plaintext key is never in our database after issuance
• Usage counters — per-key request counts by month, used for billing and quota enforcement
• Request log — each API call's endpoint path, status code, latency, cache-hit flag, key hash, and client IP address. On paid keys we also store a sanitized query string, with API-key-shaped values stripped out. Purged after 60 days by a daily retention job
• Origin IP — one address per key: the client IP seen at signup, or on the first authenticated call for keys minted by the Stripe webhook. Held on the key record for fraud / multi-account review, never overwritten, and kept for the life of the key
• Webhook URL — if you've configured one
• Stripe customer ID — for paid plans, so we can correlate webhook events with your account

Subprocessors

• Hetzner — VPS infrastructure (Helsinki, Finland / EU)
• Cloudflare — DNS, TLS termination, DDoS protection. Configured to enforce HSTS and TLS 1.2+
• Stripe — subscription billing & payment processing. We never see card details — only Stripe customer IDs and webhook events
• Resend — transactional email (account / backfill / billing notifications)
• UptimeRobot — external uptime monitoring on api.freqblog.com
• Google Drive — off-host storage for daily backup archives. Archives are encrypted on our server before upload, so Google holds ciphertext only
• Google Analytics 4 — aggregate marketing-site analytics (no API or dashboard tracking)

Data residency

The application runs on a Hetzner VPS in the EU (Helsinki, Finland). The SQLite databases live on that same VPS, on a plain ext4 filesystem — there is no full-disk or filesystem-level encryption. They are protected by file permissions instead: mode 0600, owned by the unprivileged service account that runs the API, which is also the non-root user the API container runs as. Daily archives are kept on the VPS on a 7-daily / 4-weekly / 6-monthly rotation. A copy of each archive is encrypted on the server with age — the matching decryption key is held off the VPS — and uploaded to Google Drive, where archives are retained for 30 days.

GDPR posture

We process customer data under contractual necessity (to deliver the API service) and legitimate interest (to detect abuse, enforce quotas, and improve the service).

• Right of access / erasure: email [email protected] from the address attached to your key. We respond within 30 days.
• Data Processing Addendum (DPA): available on request for any paid plan. Contact us at [email protected].
• Standard Contractual Clauses are in place where any subprocessor processes data outside the UK / EEA.

Transport security

• TLS 1.2 minimum, HSTS enabled with max-age=31536000; includeSubDomains
• API keys are accepted in the X-Api-Key header — recommended for production — or as a ?key= query parameter, which we keep for browser and curl convenience. Query-string keys can end up in browser history and intermediary logs, so we strip them from the records we control: nginx writes its access log through a format that rewrites any key= value to REDACTED, and our own request log discards API-key-shaped values — both the current fb_live_ and the legacy sk_live_ prefixes — before storing a query string
• Webhook callbacks are HTTPS-only and signed with HMAC-SHA256 (see the SDK page for verification examples)
• Cloudflare Turnstile gates the free-key signup form to prevent automated abuse

Incident reporting

If you believe your account has been compromised, or you've found a security issue affecting the service, email [email protected] with the subject SECURITY. We aim to acknowledge within 24 hours and triage within 72 hours. Please do not publicly disclose vulnerabilities until we've had a chance to ship a fix.

Service status

Live uptime, response time, and 24h / 30d availability are published at freqblog.com/status — sourced from external UptimeRobot probes that hit api.freqblog.com/health/deep and the api.freqblog.com/health/lookup canary every 5 minutes.

Contact

Operated from the United Kingdom. For any data-handling, privacy, or security question: [email protected]. We aim to reply within one business day.