Security

Email [email protected] with enough detail to reproduce the issue. You will get a human response within 3 business days, and we will tell you whether we can reproduce it and what we intend to do.

We will not pursue legal action against anyone who reports a vulnerability in good faith, stays within their own account and test data, avoids degrading the service for others, and gives us a reasonable window to fix the issue before publishing. Please do not run automated scanners against production, access other customers’ data, or attempt denial of service.

We do not currently run a paid bug bounty. Credit in our changelog is offered where a reporter wants it.

Keys are generated from a cryptographically secure random source. We store a SHA-256 hash of the token and never the token itself, so a database disclosure does not reveal usable keys, and we cannot show you a key again after it is created.

Alongside the hash we keep a non-secret prefix (for example tf_live_a1b2c3) and the last four characters, purely so you can tell your keys apart in the dashboard.

You can create multiple keys and revoke any of them independently, so rotation never requires downtime: create the new key, deploy it, then revoke the old one. Revocation takes effect immediately. Each key carries its own rate limit.

Send keys in the Authorization header, never in a query string, and never from browser JavaScript. We deliberately do not send CORS headers on the API for this reason: a key embedded in a web page is a public key.

All traffic is served over HTTPS with TLS terminated at Cloudflare. Plain HTTP requests are redirected. The origin is not directly reachable from the public internet: it is served through an outbound Cloudflare tunnel, so there is no exposed origin IP or open inbound port to attack.

Data at rest lives in managed Postgres (Neon), which encrypts stored data. Secrets and provider credentials are held in the deployment environment, never in the repository.

We store your account email, hashed API keys, and usage records (which endpoint, when, credits spent, IP address) for billing, rate limiting, and abuse prevention. Transcript results are cached to avoid refetching the same public video repeatedly.

Anonymous free-tool records (IP address and a device fingerprint used only for rate limiting) are deleted automatically after 30 days.

Deleting your account removes your associated data, subject to records we are required to keep for legal and accounting purposes. You can request access, correction, or deletion at any time. Full detail is in the privacy policy.

We do not sell personal data, and we do not use your transcript requests to train models.

These are the third parties that can touch data in the course of running the service. Note the third row in particular: when a video has no caption track, we extract its audio and send it to a speech recognition provider.

Live status, per-service uptime, and incident history are published at status.transcriptfetch.com, monitored by a third party rather than by us, so the numbers are not ours to edit. Incidents are recorded there rather than quietly resolved.

Two health endpoints are public and unauthenticated: /api/v1/health for liveness and /api/v1/health/deep, which performs a real transcript fetch and only returns 200 when actual segments come back. You are welcome to monitor both yourself.

We are a small team and we would rather be direct than imply certifications we do not hold. TranscriptFetch is not currently SOC 2 or ISO 27001 certified, and we do not have a signed BAA or FedRAMP authorisation.

We honour GDPR and CCPA data rights requests. If your procurement process needs a security questionnaire completed, a DPA signed, or a specific data residency commitment, get in touch and we will tell you honestly what we can and cannot commit to.

How we version the API, what counts as a breaking change, and the notice you get before anything is removed is documented in the API versioning policy.