How Do You Automate AI Video Creation in n8n or Make With the VdoBloom API?
Automate AI video in n8n or Make with ordinary HTTP request nodes: trigger, image, video job, webhook or polling, then store the result in Drive, Sheets or Slack.
An end-to-end automation is five steps: a trigger, an HTTP request that makes the image, an HTTP request that starts the video job, a wait or webhook step, and a place to store the result. On the VdoBloom side it is all ordinary HTTP, because there are no native n8n or Make nodes to install. A 5-second Seedance 2 Fast clip costs 24 credits at 480p and 50 at 720p, so the whole flow is priced in the same credits as the app.
Updated October 2026.
What the workflow looks like: trigger, image, video, save
The shape is the same in either tool: a new row, a form submission or a schedule starts the run; an image is generated from a product description; that image becomes the first frame of a short video; the finished file lands in Drive, a Sheet and a Slack channel.
| Step | n8n or Make module | What it calls |
|---|---|---|
| Trigger | Schedule, form or new-row trigger | Your own source |
| Image | HTTP Request | POST /images/generations |
| Video | HTTP Request | POST /videos/generations |
| Wait | Wait, loop or Webhook trigger | GET /jobs/{id} or the webhook |
| Store | Drive, Sheets, Slack modules | The result URL |
Because every step is a normal HTTPS call, the workflow does not depend on a plugin staying updated. The developer page lists the endpoints, and the API quickstart covers the individual calls in more detail.
Step 1: one generic HTTP request node with a bearer header
Create an API key in Settings, Developer. It begins with vdb_ and is shown once. Store it in the automation tool’s credential store rather than pasting it into a node that gets exported with the workflow.
Every request needs two headers:
Authorization: Bearer vdb_your_key
Content-Type: application/json
The base URL is https://vdobloom.com/api/v1. Use one HTTP request module for everything; there is no VdoBloom node to look for and nothing to install. Before the main flow, add a GET /balance call and stop the run if the remaining credits are below the cost of the batch. That one check prevents a half-finished run that has already spent credits on images but cannot pay for the video.
Step 2: start the video job and keep the job id
The image step posts a prompt and model to /images/generations with wait set to true, so the response already contains a finished image URL. Pass that URL into the video step as image_url.
{"prompt":"Product on a wooden counter, slow push in, morning light","model":"bytedance/seedance-2-fast","image_url":"https://your-storage.example/product.jpg","duration":5,"resolution":"720p","aspect_ratio":"9:16"}
Add an Idempotency-Key header with a value unique to this item, such as the row id plus a version number. Then store three fields from the response: the job id, the credit cost, and the item id from your source. The job id is what every later step needs, and the credit cost is what makes the run auditable after the fact.
Step 3: wait by polling every 20 to 60 seconds, or receive the webhook
Video takes one to ten minutes, so the job returns immediately and the workflow has to wait. There are two ways.
Polling is the simpler one. Add a Wait module set to 30 seconds, call GET /jobs/{id}, and loop back until the status is completed or failed. Cap the loop at about 20 iterations so a stuck job ends the run instead of waiting forever. This pattern works in any tool that supports a loop.
Webhooks are better for volume. Add a webhook URL to the key in Settings, Developer. VdoBloom posts a job.completed event when the render finishes, and a Webhook trigger starts the storage half of the flow. Nothing polls, so a queue of twenty clips costs twenty short runs rather than twenty long ones.
Step 4: verify the webhook signature and skip duplicate event ids
A webhook endpoint is public, so verify every call before acting on it. The request carries X-VdoBloom-Signature: t=<unix>,v1=<hex> and X-VdoBloom-Event: job.completed. Compute an HMAC-SHA256 over the timestamp, a dot, and the raw body with your signing secret, then compare it to the v1 value in constant time.
Reject anything that does not match, and reject timestamps that are too old so a captured request cannot be replayed later. Answer with any 2xx once you have accepted the event.
Duplicates are normal. A non-2xx response is retried after 30 seconds, 2 minutes, 10 minutes, 1 hour and 6 hours, and the event id stays the same across attempts. Store event ids in a small table and skip any id you have already processed. Without that check, one retry can upload the same clip twice and post it to Slack twice.
Step 5: save the result to Drive, Sheets or Slack
On completion, download or link the video URL and write it where the team will look for it. A workable split is Drive for the file, a Sheet row for the metadata, and Slack for the notification.
- Drive: store by date and product, not by job id, so the folder is browsable.
- Sheets: keep the item id, job id, model, duration, resolution, credit cost, status and file link on one row. That row is what makes a batch reviewable a month later.
- Slack: post the link with the hook or angle, and tag the person who owns the campaign.
If your source is a content calendar, the same row that triggered the run can hold the output, which keeps the automation closed. For a campaign-shaped version of this flow, see the AI UGC ads workflow.
Guardrails: check /balance first, reuse Idempotency-Key on retries
Two habits keep an automation from costing more than it should. Check /balance at the start and compute the expected spend from GET /models before the run begins. Then attach the same Idempotency-Key whenever a step is retried: repeating the request with the same key returns the original job instead of charging again, and reusing that key for a different item is refused with 422, which is your signal that the key generation is wrong.
A failed generation is refunded automatically, so a retry does not double-charge. Insufficient credits return 402 and rate limiting returns 429; both should stop the run and notify a person rather than loop. The account allows 120 requests and 20 generations per minute across all keys, which is enough for most editorial calendars but worth batching politely. Running many renders in one pass is covered in AI video batch generation; pack and plan options are on the pricing page.
Frequently asked questions
Is there a native VdoBloom node for n8n or Make?
No. Use a generic HTTP Request module with a bearer header. The workflow does not depend on a community node, and every endpoint is documented on the developer page.
Should I poll or use a webhook?
Poll every 20 to 60 seconds for a handful of jobs. Use the webhook for volume, because it starts the storage step the moment a render completes and avoids long-running loops.
How do I stop a retry from generating a second video?
Send an Idempotency-Key tied to the source item. A retry with the same key returns the original job; a different request under that key is refused with 422.
What happens when the render fails?
The job status becomes failed, the credit is refunded automatically, and no file is stored. Route the row to a review step rather than retrying the same prompt automatically.
Can the same workflow make images as well as video?
Yes. Use /images/generations with wait set to true for the still, then pass the returned URL to /videos/generations as image_url. Edits use /images/edits with one to ten image URLs.
Start with a single-item version: a trigger, an image call, a 5-second 720p Seedance 2 Fast render, and one Drive upload, with text to video open to compare prices. New accounts get 10 free credits with no card, so the first run costs nothing to try, and one-time credits never expire if you would rather not subscribe.
Ready to try it?
Create your first AI video in minutes — no credit card required.
Start Creating Free →