Video job status
/v1/videos/{job_id}A video job's state, and the link to the finished clip.
Request
job_idstringpathrequiredvid_…Responses
идёт
{
"id": "vid_9f1c4a2b7e0d4f5a8c3b6d1e2f0a7b4c",
"status": "processing",
"estimated_cost_usd": "0.95"
}Details
Needs a key in Authorization: Bearer or x-api-key.
This endpoint does more than read a row: if the job is queued or processing and has a provider id, it polls the provider inside this very request and, if the provider is done, finalizes the job — charges it and stores the result links. So the first successful poll is also what hands you the finished video. A job in unknown_submit (the submit was never confirmed) is not polled here — the reconciler finishes that one.
A terminal answer describes OUR database rather than the provider's claim, and that is not pedantry: the reconciler releases the hold of a job stuck for longer than a day (the threshold is a setting), marking it failed and refunding it. Should the provider finish after that, answering "completed" would hand out links that /content answers 404 to. Such a job honestly reports failed. While the job is NOT terminal, though, status is the provider's own word folded onto our set: pending or processing.
Cost follows the state, and the fields never overlap: estimated_cost_usd is the hold while the job runs; cost_usd is the actual charge once it is done; cost_usd: "0" once it has failed. Both are decimal strings, not JSON numbers: a number would be reprinted by the client's float printer (4.65e-05 instead of 0.0000465). duration appears only in the answer that itself drove the job to completed, and error only in the one that itself failed it; a later read of the same row carries neither, while the data links stay. A failed generation shows up here as status: "failed" inside a 200, not as an HTTP error — the only HTTP errors this endpoint returns are a missing key and someone else's job — and someone else's answers exactly like a missing one, so a leaked id confirms nothing.