Automating image-to-video creation error keep occurring

Questions
1

:bullseye: What is your goal?

To figure out the correct and reliable way to handle async video generation without errors.

:thinking: What is the problem & what have you tried?

I’m trying to automate an image to video step inside a workflow, but the video generation is async so it’s inconsistent. The POST request returns a job ID fine, but when I check the status, the video URL is often still empty or the status is still “processing”, so my filter blocks the run and the workflow stops. Sometimes it works if the render finishes quickly, other times it fails and I have to rerun.

What I’ve tried so far is adding a fixed wait (30 to 90 seconds), polling the status endpoint a few times, adding filters like “continue only if status = completed and video_url exists”, and setting retry logic. It’s better, but it still feels fragile, especially when renders take longer or the API responds with HTTP 200 but no video URL yet. I’m looking for the cleanest pattern to handle this reliably without guessing wait times.

:clipboard: Error messages or input/output bundles

“Bundle did not pass through the filter” (because video_url is empty)

1 Like
3

Hi Adeola,

There are two patterns which you may consider to make your workflow more robust.

Pattern 1: Webhook / Callback (if the API supports it) - Best possible solution. Zero polling. Zero guessing. Only if the service you are using is supporting it.

Flow

  1. You POST /generate-video

  2. You include a callback_url (which is a Make webhook scenario’s URL) - either on a request level or as a setting in the image-2-video provider

  3. API responds immediately with job_id

  4. API later calls your webhook when:

    • completed

    • failed

    • timed out

  5. Your scenario implemented as a webhook is using the generated video

Pattern 2: Decoupled polling via a separate “job watcher” scenario

If no callback exists, this is the other most reliable Make.com-native pattern.

The key idea is to do NOT block the original workflow but rather persist the job and let another scenario watch it.

Scenario A — Job Creator

  • Sends the image → video request

  • Stores the job_id and status (Make data table, spreadsheet, etc.)

  • Ends immediately

Scenario B — Job Watcher (scheduled / triggered when a new entry is added)

  • Periodically checks job statuses

  • Decides when it’s actually done based on the response

  • Updates the data row if the status of the job was changed

  • Triggers downstream logic when the job is completed

Both of the above will remove the timing assumptions from your scenario that are very unreliable and at some point may also lead to your scenario timing out if the remote service is slow at the moment. You may read about “Exponential Backoff” to see for a third pattern of how similar cases are implemented, however, I don’t think it is the appropriate pattern for your use case/workflow.

BTW, the message “The bundle did not pass through the filter” is not an error in the actual terms of errors (it doesn’t allow error handling or breaks your scenario), it just indicates that the bundle did not pass through the filter but the scenario run is successful.

I hope this helps.

1 Like
4

I actually think the tool I’m using for the image-to-video step (PixelMotion) supports a callback, so I’m going to test that first. If I can pass a callback URL and have it ping my webhook when the render is completed or failed, that basically removes the whole waiting and polling stress.

If for any reason that doesn’t work as expected, I’ll fall back to the separate job watcher scenario you mentioned. Either way, this is a much cleaner direction than what I’m doing now.

3 Likes