A companion piece walks through this from the outside: a plain-English request, and a large video file that needed an editor's review ends up as a playable link — no dashboard, no file-transfer service, no dedicated media asset management system.
This post is the inside view: the actual sequence of REST calls open-videocore's own API executes to get there, endpoint by endpoint, for anyone who wants to drive it directly instead of taking the outcome on faith.
open-videocore's own docs walk through this exact scenario at videocore.pages.osaas.io/agentic-examples.html, framed as an example prompt:
"I have a 4.2 GB video file at ~/Desktop/keynote-final.mp4 that Jana needs to review by Friday. Upload it to my open-videocore instance, wait until it's ready, package it for streaming, and give me a playback link I can send her."
One sentence, no API knowledge in it at all. No mention of multipart uploads, no mention of polling, no mention of packaging formats. Just what the person wants: the file needs to end up somewhere Jana can watch it.
The interesting part isn't that an agent can turn a sentence like that into API calls — most agents can chain a few HTTP requests together if you point them at documentation. The interesting part is what the actual call sequence looks like once you follow it end to end, because a 4.2 GB file is exactly the size where the easy path (one PUT request with the whole file in the body) stops being an option. That's what the multipart sequence below exists to handle.
The seven calls
1. Create the asset record. POST /api/v1/assets/ registers the upload before any bytes move. This is the step that gives the agent an asset ID to reference for everything that follows, and it's also the natural point where metadata — a title, a description, whatever your workflow needs — gets attached.
2. Start a multipart upload. POST /api/v1/assets/{id}/multipart/initiate. A 4.2 GB file is not something you hand to a single HTTP request and hope for the best; a dropped connection halfway through means starting over. Multipart upload splits the file into chunks that upload independently and can be retried individually.
3. Get an upload URL per chunk. GET /api/v1/assets/{id}/multipart/{uploadId}/part-url, called once per chunk. Each call hands back a URL the agent can PUT that specific chunk to. This is the part of the sequence that actually loops: for a 4.2 GB file split into, say, 50 MB parts, that's roughly 85 calls to this endpoint before the upload is assembled.
4. Complete the multipart upload. POST /api/v1/assets/{id}/multipart/{uploadId}/complete, once all chunks are up. This is where open-videocore stitches the parts back into one asset.
5. Poll until the upload is ready. GET /api/v1/assets/{id}, called repeatedly until the asset's status field leaves uploading. This is the "wait until it's ready" clause in the original prompt, made concrete: not a fixed delay, an actual poll loop against a status field.
6. Execute the transcode-and-package pipeline. POST /api/v1/assets/{id}/execute, then poll the execution the same way step 5 polled the upload. This is the step that turns a raw uploaded file into something a browser or a TV app can actually stream, and it's the step the original prompt referred to as "package it for streaming."
7. Get the playback link. GET /api/v1/assets/{id}/delivery. This is the URL the agent hands back — the one that goes in the message to Jana.
Seven calls, in a fixed order, each one gated on the previous one finishing. None of it is exotic REST design. What makes it worth writing up is that the docs page states the whole thing is "a plain REST API with a committed openapi.json," and that interactive, always-current reference docs are also served at /api-docs on any running instance. An agent — or a person, or a script — isn't reverse-engineering behavior from prose. It's reading a machine-readable spec against a live server.
The part that's easy to miss: authentication
If the agent driving this sequence is already connected to OSC, for example through the OSC MCP server, it doesn't need your instance URL and it doesn't need a bearer token handed to it. It can look up your open-videocore service instance itself and dispatch a call through OSC's MCP layer, which authenticates it automatically. The agent never sees or handles a bearer token, because at no point does it hold one. That's a smaller detail than the seven-step pipeline, but it's the one that actually changes what "give an agent this task" means in practice: there's no credential typed into a chat window sitting in that agent's context, retrievable if the conversation gets logged or shared.
A boundary worth being precise about
This is what open-videocore's own REST API does, on a deployed open-videocore instance. It's the engine, not the hosted product built on top of it. If you're wondering whether the same thing is true of Media Convert as a managed OSC product today, the honest answer is that its customer-facing job endpoints aren't built for this yet — they run through a browser session, not a token an agent could hold. That gap is filed internally as a follow-up. What's described above is real for open-videocore's own API, callable exactly as shown, right now.
What this post is, and isn't
The seven-call sequence and the authentication behaviour above are quoted and paraphrased from open-videocore's own docs page — this is the documented shape of the capability, not a specific run staged for this post. For an actual live run against a real instance — a real file, a real 5-rendition HLS output, a real playback link, screenshot included — see the companion piece. That one happened this week, unscripted, for an ordinary reason: someone had a large file and a colleague who needed to review it by a deadline.
Try it → app.osaas.io
Top comments (0)