Состояние видео-джобы
/v1/videos/{job_id}Состояние видео-джобы и ссылка на готовый ролик.
Запрос
job_idstringpathобязательноvid_…Ответы
идёт
{
"id": "vid_9f1c4a2b7e0d4f5a8c3b6d1e2f0a7b4c",
"status": "processing",
"estimated_cost_usd": "0.95"
}Подробности
Нужен ключ в заголовке Authorization: Bearer или x-api-key.
Ручка не просто читает строку: если джоба в queued или processing и у неё есть id у провайдера, она опрашивает провайдера прямо в этом запросе и, если тот закончил, финализирует джобу — списывает деньги и сохраняет ссылки на результат. Поэтому первый же успешный опрос и отдаёт готовое видео. Джобу в unknown_submit (сабмит не подтвердился) эта ручка не опрашивает — её добивает реконсайлер.
Терминальный ответ описывает состояние НАШЕЙ базы, а не слова провайдера, и это не придирка: реконсайлер освобождает резерв у джобы, которая висит дольше суток (порог — настройка), помечая её failed и возвращая деньги. Если провайдер закончит после этого, ответ «completed» выдал бы ссылки, на которые /content отвечает 404. Такая джоба честно отвечает failed. А пока джоба не терминальна, status — это как раз слово провайдера, приведённое к нашему набору: pending или processing.
Стоимость приходит по состоянию, и поля не пересекаются: estimated_cost_usd — резерв, пока джоба идёт; cost_usd — фактическое списание, когда готово; cost_usd: "0" — когда провалено. Оба поля — строки с десятичной записью, а не JSON-числа: число клиентский float-принтер переписал бы (4.65e-05 вместо 0.0000465). duration есть только в том ответе, который сам довёл джобу до completed, а error — только в том, который сам её провалил; при повторном чтении строки этих полей нет, ссылки в data остаются. Провал генерации здесь виден как status: "failed" в теле 200, а не как HTTP-ошибка — HTTP-ошибку по этой ручке даёт только отсутствующий ключ или чужая джоба, — а чужая отвечает ровно как несуществующая, чтобы утёкший id ничего не подтверждал.