Reprocess an already uploaded and completed video file. This is useful when insights need to be regenerated or logic has been updated on the backend. Reprocessing can optionally notify your system via a callback URL.

language is optional. Without it the video keeps the language it already has (detected from the audio when it has none). With it, the video and its companion audio are processed in that language, and the video remembers it for later reprocesses. It is checked before anything is charged, so an unsupported code is refused with 422 invalid_language and costs nothing. It is only used by a request that starts a run (a failed video, or reprocess=true); on a request that does not, it is ignored.

The video's companion audio is transcribed again in that language, as part of the video's charge: a failed one as before, and a completed one too (its language-range edits are discarded). One that is still processing is not restarted; fix it with PUT /v1/audios/{audio_id} once it has finished. One busy with a language-range job is refused with 409 audio_busy. GET on the video returns the stored multilingual and expected_languages, but not the stored language.

multilingual and expected_languages are the language hints (expected_languages is the set of languages the audio may contain, up to 5; see the field descriptions). Each is optional and, unlike on the audio endpoint, an omitted one keeps what the video has: multilingual=false turns the switch off and an empty expected_languages removes the set, which is how a video returns to unrestricted detection. They are checked with language before anything is charged (an invalid one is 422 invalid_language and costs nothing), and language must be in the set the video will have: naming only language outside the stored set is refused the same way, so send the set too (or an empty one) to change both. Naming any of the three also re-runs a completed companion audio, and the companion is given the video's resulting hints.