I’m building an unofficial Frame.io client for Android (Kotlin Multiplatform, aimed at power users), and transcripts are the one feature I can see in the web UI but cannot reach from the API at all.
What’s missing. GET /v4/accounts/{account_id}/files/{file_id} returns media_links for thumbnails, originals and the transcoded renditions, but nothing for the transcript Frame.io generates. There’s no transcript endpoint, no media_link type, and no field on the file resource. So a transcript that already exists on Frame.io’s side is reachable only by a human opening the web, desktop or iOS app.
I know this has been raised. There’s an existing thread on batch-exporting transcripts and comments, where the answer has been “on the roadmap” (July 2025), then “added to the ticket” (November 2025), then “still on the list, no updates” (January and February 2026). I’m opening a separate thread rather than piling on, because my ask is narrower and, I think, cheaper: not a batch export tool, just read access to a transcript that has already been generated.
Concrete use case. A user records or uploads video, Frame.io transcribes it, and they want the captions on their phone — to read along, to hand to an editor, or to attach to a cut. Today that round-trip requires a desktop. For a mobile client this is the difference between “I can review here” and “I’ll do it later at my laptop”.
What would be enough. Any one of these solves it — listed cheapest first, since I’d rather have something narrow soon than something complete later:
- A transcript entry in the existing media_links collection, pointing at a downloadable artifact. No new endpoint, no new shape — it reuses everything clients already implement for renditions.
- GET /v4/accounts/{account_id}/files/{file_id}/transcript, returning the transcript with a format parameter for vtt / srt / txt, matching what the UI’s export already produces.
- Read-only, listing what exists. I don’t need to trigger generation, delete, or edit — those can stay UI-only.
Two details that matter for a client: the language of the transcript should be identifiable (transcription supports 27, so a file may plausibly have more than one), and the response should distinguish “not generated yet” from “this account can’t generate transcripts” — otherwise a client has to guess which message to show the user.
Happy to be a guinea pig. If this lands behind an experimental flag or early-access header, I’ll take it in that form and report back on what breaks — an unofficial client is a reasonable place to find the sharp edges before it’s stable.
One question while I’m here: is transcription itself plan-gated? The help centre documents which roles can generate, delete and export, but I couldn’t find whether the feature depends on the plan. I ask because I’ve already hit a plan gate on secure sharing, and I’d like to know before building against this whether some accounts simply won’t have it.