Trust & reliability

Uptime, per-service status, and full incident history are at status.transcriptfetch.com. It is recorded by an independent monitoring provider, not by us, so the figures are not ours to edit, and outages appear there whether we like it or not.

You can also monitor us directly, without an account. Two public endpoints:

• GET /api/v1/health — liveness.
• GET /api/v1/health/deep — performs a real transcript fetch and returns 200 only when actual segments come back. A green light here means the scraper is genuinely working, not merely that the web server is up.

We publish a deep health check precisely because a shallow one can be green while the product is broken.

The versioning policy states exactly what counts as a breaking change, what can ship additively without notice, and the notice you get if a version is ever retired (at least 12 months, announced in the changelog, by email, and with a Deprecation response header).

Nothing is deprecated today, and the older unversioned routes still work. Shipped changes are recorded in the changelog.

The security page covers how API keys are stored (SHA-256 hashed, never in plaintext), encryption in transit, what we retain and for how long, and the full subprocessor list including the speech-recognition provider that receives audio when a video has no captions.

Vulnerability reports go to the address in /.well-known/security.txt, with a 3-business-day response commitment and safe-harbour terms for good-faith research.

We are not SOC 2 or ISO 27001 certified. If your procurement needs that, say so and we will tell you honestly where we stand rather than stall.

We have deliberately not put customer logos or star ratings on this page. Anyone can write those. Instead, these are third-party surfaces where our existence, release history, and activity are public record and outside our control:

• Official MCP Registrycom.transcriptfetch/youtube-transcripts, status: active
• PyPItranscriptfetch-sdk, with public release history and download counts
• npmtranscriptfetch, with public release history and download counts
• npm (n8n)n8n-nodes-transcriptfetch, the community node
• Postman API NetworkPublished collection and publisher profile
• GitHubSDK source, public issue history
• WikidataQ140460286, an independently maintained entity record

Package registries publish download counts and release dates we cannot edit. Read them with the usual caveat that registry download numbers include mirrors, scanners, and CI, so treat them as directional.

TranscriptFetch is built and operated by Chandler Casey. Not a faceless brand: you can find the same person on LinkedIn and X, and support replies come from a human.

This is a small operation, which is a real trade-off and worth stating plainly: you get direct access to the person who wrote the code and fast fixes, without the procurement apparatus of a large vendor. If you need a 24/7 on-call rota with contractual response times today, we are not that yet.

Revenue comes from monthly credit subscriptions and top-ups. Customers paying for the product is the entire business model: there is no ad-supported tier and no data resale, and we do not use your requests to train models.

The free tier is 100 credits a month, sized to be a genuine trial rather than a subsidy. One credit equals one successful response, and failed requests are never charged, so the incentives point the same way as yours: we only get paid when the API actually works.

The one thing that cannot be built quickly is operating history. TranscriptFetch is new. We do not have years of continuous uptime to point at, and any evaluation should weigh that.

What we can do is make the record public as it accumulates: outages land on the status page, platform breakages and their fixes are dated in the changelog, and none of it gets quietly deleted. If you are weighing this for a critical path, a reasonable position is to build behind a thin interface so any provider can be swapped, which is good engineering regardless of vendor.