Creative automation API: plug Nubu into your pipeline
Nubu's creative automation API lets your own systems start campaign flows, receive the finished statics and videos, and keep a DAM in sync.
Nubu Team··9 minute read
Most marketing teams already run a production pipeline of some kind. A product database knows what is on offer this week, a digital asset management system holds the approved photography, a planning tool decides when each campaign goes live, and a script or two holds it all together. Nubu builds the creative: one template becomes hundreds of finished statics and videos for every market and language, rendered, reviewed and delivered. The Nubu creative automation API connects the two, so the systems you already trust can start a campaign flow, hand over the values and the pictures, and get every finished render back where it belongs.
This post is about what that connection looks like in practice rather than how to code it. The working details, every call and every field, live in the API docs. Here we show the shape of an integration with the same node graphs you would build inside Nubu, and we are plain about where the boundaries sit. The API is part of Nubu rather than a separate product, and it is included on every paid plan.
It is also a vendor describing its own API, so read the claims as claims and check them against the docs. Everything below describes what ships today: nothing is a roadmap item, and nothing is hidden behind a sales call.
The Nubu API is the way your own software talks to Nubu without anyone opening the app. It can put files into the asset library, upload the templates your motion designers export, start a campaign flow with values of its own, follow that run while its creatives are reviewed and rendered, and receive every finished render in a system of your choosing. It is available on every paid plan, with no separate licence.
In practice it does five things:
Assets. Upload, replace and delete files in the library, into folders if that is how you organise them. Files uploaded this way are ordinary library assets: they get the same previews and the same duplicate detection, and they count towards the same storage as anything uploaded by hand.
Templates. Upload the package Nubu Builder exports, and Nubu reads and checks it exactly as the upload drawer in the app would.
Flow runs. Start a flow that contains an API Trigger node, with your values and your asset ids, then follow the run as its creatives are built, approved and rendered.
Creatives. Approve, re-render, download and delete creatives from your own tooling.
Delivery. Receive the finished render in your own system through an API Request node, and be told every time a run changes state instead of asking.
The two nodes in that list are the point of this post. The API Trigger node is where your pipeline enters a flow; the API Request node is where the renders leave it. Both sit on the same canvas as every other node, and the flow between them is the one your team already builds in the node editor.
How do you plug a campaign flow into your own pipeline?#
You add an API Trigger node to the flow and list the fields your system will send: a market, a headline, a hero image, whatever the campaign needs. Each field connects into the flow exactly where a node of that kind would, so a headline from your product database lands in the template's headline slot and a market from your planning tool gates the languages that follow. From then on your software starts the flow by sending those values, and Nubu builds every variant the flow describes.
Here is the shape of it. Drag the nodes around; it is the same graph you would see in the editor.
Reading left to right: the API Trigger carries the three fields the call supplies, with the example call the node writes for you underneath. The Languages and Captions lists belong to the flow, not to the call, which is how one call becomes several variants without your system knowing anything about localisation. The Template receives everything, the Output turns it into renders, and the API Request node at the end sends them back to the pipeline that started the job.
What happens on one call, in order:
Your system sends the values, plus the ids of any images or footage already in the library. The flow's own lists do the multiplying.
Nubu builds the run: every creative the flow describes, exactly as pressing Build in the editor would.
The creatives wait for review, or go straight to the render queue. Each call decides which, so a weekly offer can render unattended while a new campaign waits for a person to look at it first.
Renders happen on the farm, traceable like any other render: which template and version, which values, when each step happened.
The finished renders are delivered or downloaded. An API Request node pushes them to your endpoint; the API can also hand them to you on request.
One detail matters more than it sounds. Sending the same job twice never renders it twice: a retry from your side, or the same offer sent by two scripts, is recognised and reuses the creatives that already exist. Pipelines retry things, and Nubu is built on the assumption that they will. The precise behaviour is documented under triggering a flow and runs and creatives.
Wherever the flow's Output nodes say. An Output can feed several destinations at once: paused ads in your Meta or Google ad account, a ZIP download for everything else, and, with an API Request node, your own system. The API Request node takes the address to deliver to, the credential your endpoint expects, and whether to send the file itself or a link to fetch it. Every creative that renders through that Output is then delivered automatically, in the background, with no one keeping Nubu open.
Each delivery carries more than the file. It includes the values the render was made from, the market, the language, the headline and the rest, in a shape your system can file against without guessing. So the same event that drops a video into your storage can also tell your CMS which product page it belongs to. Very large renders arrive as a link rather than a file, whatever the node is set to, so a long video never jams the delivery.
Delivery is built for the unglamorous cases. If your endpoint is down, Nubu retries, and if it stays down the failure is recorded on the creative, visible in the app and through the API, while the render itself stays safely in Nubu. A re-render delivers again once the new file lands. The full behaviour is in API Request delivery.
If you would rather be told than ask, a flow run can call your system back every time something changes: creatives built, approved, queued, rendering, rendered or failed, and each delivery's outcome. Callbacks are signed so your endpoint can prove they came from Nubu, and they are described in callbacks. Paired with paused-ad delivery, which keeps every ad switched off until a person turns it on, this is how a pipeline stays automatic without ever publishing on its own. The reasoning behind paused ads is in why paused ads protect learning.
How does the API keep your DAM in sync with Nubu?#
Assets flow in through the API as ordinary library assets, with the ids you choose to remember, and finished renders flow back out to the address your DAM listens on. Your DAM stays the source of truth for approved photography and footage; the Nubu library is simply where flows look for it. When a file is replaced or retired in the DAM, the same API replaces or deletes it in Nubu, so the two never quietly drift apart.
The loop runs like this. A new product shoot lands in your DAM, and your integration uploads the approved images into a library folder, keeping each asset id against the DAM record. When the launch is scheduled, it starts the flow with those ids and the headline, and asks for the creatives to render straight away. The renders come back to the DAM as links it fetches at its own pace, filed under the product they belong to, with the values they were made from alongside. Nothing was renamed by hand, nothing was dragged between folders, and the people involved spent their time on the creative, not the plumbing. The mechanics of the upload, including folders and large files, are in uploading assets and folders; how the library behaves is in assets.
Nubu is not a digital asset management system and does not try to be one. It holds the media a campaign needs, with previews, folders, tags and duplicate detection, and it keeps every render it produces. If your organisation already runs a DAM, keep it as the system of record and let the API carry files in one direction and renders in the other.
What stays the same: review, approval and traceability#
Nothing about the API bypasses Nubu. A run started by your software is a normal run: its creatives appear in the campaign, its renders appear in the renders list, and the people on your team can open, comment on and approve them exactly as before. Review and approval are still human steps, and nothing publishes itself: ads delivered to Meta and Google land paused, and a delivery to your own endpoint is a file arriving, not a campaign going live.
Traceability holds too. Every render records which template and version produced it, which values went in, who or what created it, and when each step happened, whether a person pressed Build or a script sent a call. And access is deliberate: your organisation creates its own keys in Settings, each with only the permissions that system needs, and can revoke any of them at any time. A key acts as the organisation rather than as a person, so an automated run never borrows anyone's identity. The details are in authentication and keys.
Every paid plan: Starter, Pro and Business+. There is no separate API tier and no separate price for it; the API is part of the plan your organisation is already on. The free plan is for trying Nubu on your own and does not include it. Plans and their seat prices are on the pricing page.
You need someone who can call a web service from the system you want to connect, and a couple of hours of their time. The marketing side needs no code at all: producers build the flow, add the API Trigger node and name its fields; the integration then sends those fields. The API overview is written for the person doing the connecting, with a complete example call for every step.
Can we start with a spreadsheet instead of an integration?#
Yes, and many teams should. The CSV node pipes spreadsheet columns into a flow with no code at all, and it is the right first step when the data changes weekly rather than hourly. The API becomes worthwhile when a system already holds the values and someone is re-typing them. Both routes feed the same templates; see CSV to video ads and product feed to video ads.
What happens if our system is down when a render finishes?#
Nubu retries the delivery, then records the failure on the creative where your team can see it. The render itself is unaffected and stays in Nubu, so it can be delivered again or downloaded later; nothing is lost because an endpoint was unavailable for an afternoon.
Yes. It takes the package Nubu Builder exports and checks it exactly as the upload drawer in the app would, naming every problem if the package is refused. Replacing a template through the API versions it, as it does in the app, so campaigns that use it keep working. See uploading templates.
Yes. A repeated call reuses the creatives that already exist instead of building and rendering them again, so a retry from your pipeline can never double a render bill or a review queue.
The useful question is not whether your pipeline could talk to Nubu but which single flow would save the most re-typing if it did. Pick that one: the weekly offer, the product launch, the market rollout. Add an API Trigger node, name the fields, and let the integration send them. Put an API Request node on the end if the renders need to land somewhere specific. Everything else, the lists, the templates, the review, stays exactly the flow your team already knows.
The complete reference is in the API docs, the plans that include it are on the pricing page, and the node editor the API plugs into is described in the case for a node-based editor. Your pipeline already knows what to make; now it can ask for it.
