Changelog
Fixed

Compose refuses clip URLs it cannot reach at submit

A compose clip on localhost or a private network is refused at submit with the clip's path, instead of a render that fails without a reason.

API

A compose timeline whose clip pointed at your own machine, like http://localhost:3000/video.mp4, was accepted, sent to the render, and failed a few seconds later as “The compose render did not finish.” Nothing said which clip was wrong or why.

That document is now refused at submit with a 400, before a job is created or anything is billed. The error names the address and the fix, and details[0].path points at the clip:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Invalid job parameters: localhost is a private address that Rendobar cannot reach. Upload the file, or use a public URL.",
    "details": [{ "path": ["timeline", "tracks", 0, "clips", 1, "asset", "src"] }]
  }
}
  • Where it applies. Every URL a render downloads: clip, subtitles and animation sources, a wipe’s map, effect files like a LUT, and the assets you hand to AI assist.
  • Validate sees it too. POST /compose/validate and the MCP validate_compose tool report the same problem at the same path, so you can catch it before you submit.
  • Share pages count. A Dropbox preview link or a OneDrive share link is refused the same way, with the direct-link fix.
  • What still works. Public URLs, and files you uploaded, in any form: asset://<id>, storage://<id>/<path>, or the asset’s content URL.

A job that only learns its source is unreachable once the render starts now fails right away with INPUT_URL_BLOCKED and the reason, instead of the generic message. It follows the same idea as clearer timeout errors: a failure names the thing to change.

To use a file from your machine, upload it first and pass its asset:// URL. Uploads and clip sources are covered in the compose docs.

Share