2026-11-04 · 4 min read

Captions for News Videos with an API

News video lives in feeds where autoplay is muted and on screens where the sound stays off. A clip whose facts only exist in the audio loses the story for a big share of viewers. Burned in captions keep the reporting readable everywhere the clip travels.

Newsrooms also repost the same clip across platforms with different caption conventions. Burning one captioned master into the frames removes that per-platform drift, because the text is part of the video, not a track each app renders differently.

Submit the clip

curl -X POST https://api.caption.sh/v1/videos \
  -H "Authorization: Bearer $CAPTION_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"source_url": "https://example.com/video.mp4", "options": {"font": "inter"}}'

# response
# {"job_id": "job_8f3k..."}

Poll for the finished render

Rendering is asynchronous, so the submit response is a job id. Poll the job endpoint until it reports done or error, with your own timeout as the third exit.

curl https://api.caption.sh/v1/jobs/job_8f3k... \
  -H "Authorization: Bearer $CAPTION_API_KEY"

# poll every few seconds until status is done or error
# {"job_id": "job_8f3k...", "status": "done", ...}

What to know before you batch

  • Submissions are rate limited per API key. A 429 response means wait a moment and retry, it does not mean the job failed.
  • Rendering is prepaid at $0.10 per minute of video. A 402 response means the balance is empty, so top up before retrying.
  • Every render needs a bounded poll loop with three exits: done, error, and your own timeout. Do not poll forever.
  • The API documents no webhook surface, so polling is the intended way to learn a job finished.

For breaking coverage, submit the clip as soon as it is cut rather than batching at the end of the day. Renders run independently, so early clips can publish while later ones are still processing.

Back to all articles