Security & Data Handling
Plain-language summary of what data the FreqBlog Music Metadata API processes, how long we keep it, who we share it with, and how to reach a human if you need more.
Audio uploaded to /analyze is never written to disk. Files arrive over TLS, are read into volatile memory, analysed by Essentia / Librosa in-process, and discarded the moment the response is sent. No copy, no temp file, 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.
The catalog is built from public sources only:
We never crawl, scrape, or ingest paid streaming services in violation of their terms.
SHA-256(key); the plaintext key is never in our database after issuanceapi.freqblog.comThe 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.
We process customer data under contractual necessity (to deliver the API service) and legitimate interest (to detect abuse, enforce quotas, and improve the service).
max-age=31536000; includeSubDomainsX-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 sk_live_-shaped values before storing a query stringIf 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.
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.
Operated from the United Kingdom. For any data-handling, privacy, or security question: [email protected]. We aim to reply within one business day.