Use a Zap if the person who owns the workflow is not a developer and the trigger is something Zapier already watches. Use an API call if a developer owns the workflow, or if the job data comes from your own application. Both routes end in the same place, a job sitting in a QUE campaign waiting for a satellite to render it, so the real question is who will build it, who will keep it running, and what you need it to do.
This page is about that choice. It is not a setup guide. If you want the steps, our pages on the QUE API, keys and your first job and on sending render jobs to QUE with the API cover the mechanics. Here we compare the two routes the way you would compare them before committing a team to one.
What both routes do, and where they differ
Start with what is the same, because it is more than the two routes suggest. A QUE job is a set of properties for one rendered output of an autograf. Our documentation suggests thinking of it as a row of cells, with the property keys as column headers and the values as the cells. A campaign holds jobs and supplies defaults. When a job arrives without an autograf path or a satellite, QUE fills in the campaign’s defaults, and it sets the render-status to ready unless the request says otherwise.
A Zap that ends in the QUE app’s Insert Job action and a POST request to the jobs endpoint are two ways to hand QUE the same thing. Neither route renders anything. The render happens on a satellite, a machine with Templater installed, once the Bot is enabled and picks up jobs that are ready. Neither route changes how the video looks. The choice is about plumbing, and plumbing has real consequences for cost, ownership and failure handling.
Here is where they part ways.
- Who builds it. Our help page describes Zapier as a no-code or low-code service for video post-production professionals who are not necessarily developers and do not have the time to stand up a bespoke system. A direct API integration is written in code, by someone comfortable with HTTP requests and authentication headers.
- Where the trigger lives. In Zapier, a trigger is an event in another app, and the QUE integration lists New Job and Updated Job as triggers of its own. In an API integration, the trigger is whatever your own code decides it is.
- What operations you have. The Zapier integration lists Insert Job and Update Job as example actions. The API reference documents more: creating a job, importing a list of jobs in one request, retrieving jobs in a campaign, updating a job, deleting a job, and endpoints for campaigns, autografs and satellites.
- Who owns the connection. With Zapier, your Zaps live in a Zapier account, and Zapier has its own free and paid tiers. With the API, the connection lives in your code and your hosting, and you carry whatever responsibility comes with that.
Two routes
Zap vs. API call at a glance
- Who builds it?
- Zapier ZapNo-code or low-code; no developer needed
- Direct API callWritten in code by someone comfortable with HTTP requests
- Where does the trigger live?
- Zapier ZapAn event in another app Zapier already watches
- Direct API callWhatever your own code decides it is
- Who owns the connection?
- Zapier ZapLives in a Zapier account with its own tiers
- Direct API callLives in your code and your hosting
Neither is better in the abstract. Pick by who will maintain it six months from now.
API operations
What the API lets you do
| Operation | Method | What it acts on |
|---|---|---|
| Create a job | POST | Jobs endpoint |
| Import a list of jobs | Single request | Campaign, sends array of job objects |
| Retrieve jobs | GET | Jobs in a campaign |
| Update a job | PUT | Job properties |
| Delete a job | Permanent, no recovery | A single job |
| Manage campaigns, autografs, satellites | Separate endpoints | Campaigns, autografs, satellites |
Notice that the third point is a difference in what we document, not a statement about what Zapier can or cannot do. Zapier is a separate company’s product, and what its platform allows is its own business. We can tell you what the QUE app on Zapier lists. We can also tell you that our help page says it should be possible to connect any API connection or workflow automation tool to QUE through its API. If you already use a different provider, the docs point you to the API reference and to your provider’s instructions for connecting to a custom API.
When a Zap is the right call
A Zap wins when speed of setup matters more than control. Our help page says you can connect with an API key, a nickname for the connection, and the API URL, and the default URL is pre-filled. You only change it for a dedicated or custom deployment. You can also reach the integration from the Integrations page of the QUE Dash, where you can start from a pre-made Zap or search Zapier’s library of more than 5,000 apps. For someone who has never written a line of code, that is a short road from idea to a working prototype.
Here is a hypothetical to make the fit clear. It is invented for illustration. Imagine a small post-production team that makes a lower-third graphic for each guest on a recurring show. The guest’s name and title arrive from a form that a coordinator fills in. The motion designer owns the After Effects project and the Templater mapping. Nobody on the team writes code. A Zap that watches the form and inserts a job into the show’s campaign suits that team. The designer can read the Zap, change it, and turn it off, and the person who understands the graphic stays in charge of the plumbing.
There are reasons beyond skill to pick a Zap. A prototype is one. If you are still deciding whether the whole pipeline works, you want to find out in an afternoon, not after a sprint. Another is a trigger that Zapier already handles. If your data starts in an app that Zapier can watch, you skip writing and hosting the code that watches it. A third is the Updated Job trigger. If you want something to happen when a job changes, the QUE app lists an Updated Job trigger, so check in Zapier whether it covers what you need before you write your own polling code.
Now the costs. A Zap is another account, with its own tiers and its own limits that you should read on Zapier’s pages rather than take from us. It is also another place to look when something breaks. When a job fails to appear in QUE, the cause might be in the form, in the Zap, in the connection, or in QUE, and you will need to check each. The key is a single point of failure too. Our help page warns that generating a new QUE API key invalidates the previous one, so any Zap using the old key stops working until you update the connection.
Last, a Zap suits modest, event-shaped work, such as one row in, one job out. We do not have a source that says how a Zap behaves with a very large import, so we are not going to guess. If your plan is to push a big list at QUE in one go, read the next section.
When an API call is the right call
Pick the API when the job data comes from your own software, when a developer is already on the project, or when you need operations the Zapier integration does not list. The clearest example is bulk work. The API has a batch endpoint that imports multiple jobs into a campaign in a single request. You send the campaign’s ID and an array of job objects, and QUE returns a count of how many jobs were added. If you are creating a few hundred jobs from a database at once, one request that carries the whole array is a cleaner fit than hundreds of separate triggers.
A second hypothetical, also invented. Imagine a developer at an agency that builds a customer portal. When a customer finishes a form in the portal, the portal needs to create a personalized video. The portal already has the customer’s data, the authentication, and the logging. Adding a POST request to the jobs endpoint is a small step for that code, and it keeps the whole flow inside the system the developer already maintains. Sending that data out to a third-party automation service and back would add a hop with nothing to show for it.
The API route puts several things directly in your hands.
- Authentication. You send your API key as a Bearer token in the request headers. Our docs suggest storing it as a variable in a tool such as Postman so you only have to update it in one place after a key change. In real code, that means keeping it in your environment configuration and never in a public repository.
- Error handling. Your code decides what happens when a request fails. You can retry, log, alert or stop.
- Data shaping. A job’s keys can be any properties your autograf maps, plus Templater’s reserved names such as output for the output file name and target for the target composition. Your code can build those from any source without a middle step.
- Updates and cleanup. The API can update a job’s properties with a PUT request, and it can delete a job. Be careful with the last one. Our docs say deleting a job is permanent and there is no way to recover it. Also note that a key cannot be removed from a job, only set to an empty string.
The costs of the API route are the mirror image of the Zap’s. You need a developer, and the developer needs time. You own the failure modes, which means you own the monitoring, the retries and the on-call. Our docs also give a warning about satellites that applies to anyone scripting against the API: updating or removing a satellite outside of Templater or the QUE Dash can have an adverse effect on existing jobs. If you are tempted to automate satellite management, go slowly. The endpoints to script are the ones for jobs.
There is one more reason to choose the API. Some organizations run a dedicated deployment of QUE, either inside Dataclay’s cloud or in their own infrastructure. In that case the API URL differs from the default. A Zap can handle it, since the URL is a field you can change in the connection. But if your company already has strict rules about which services may touch production systems, an in-house integration may be easier to approve than a third-party platform in the middle. That is a question for your security team, not a limit of Zapier.
A way to decide, and a note on mixing the two
If you are still unsure, run through these questions in order. The first one that gives a clear answer is enough.
- Does anyone on the team write and maintain code for this workflow? If nobody does, start with a Zap. If a developer is already assigned, start with the API.
- Does the data originate in an app Zapier already watches, or in your own system? An app points to a Zap. Your own system points to the API.
- Do you need to import a large list at once? The batch endpoint points to the API.
- Do you need to react when a job changes state? The Updated Job trigger points to a Zap, though your own code can poll the API for the same information.
- Do you need to retry, log or alert in a specific way when something fails? That points to the API.
How to decide
Run these questions in order
-
Does anyone write and maintain code for this workflow?If nobody does, start with a Zap.
-
Does the data originate in an app Zapier already watches, or in your own system?An app points to a Zap.
-
Do you need to import a large list at once?The batch endpoint points to the API.
-
Do you need to react when a job changes state?The Updated Job trigger points to a Zap, though your own code can poll the API for the same information.
-
Do you need to retry, log or alert in a specific way when something fails?That points to the API.
You can also mix them without trouble, because both routes write to the same campaign. A team might begin with a Zap to prove the idea, then replace it with an API call once the volume or the requirements grow. Since the job format is the same, the autograf, the campaign and the satellite do not change when you swap the plumbing. That is worth keeping in mind. Choosing a Zap first is not a trap, as long as you keep your job keys simple and documented so that a developer can reproduce the same job later.
One thing is easy to forget. Whichever route you pick, the render-status of every job still moves through the same states as Templater works through it: ready, queued, processing, then done, or canceled, or an error code when something fails. Plan your monitoring around that, and read what each render status means before you go live. It will save you from the situation where jobs are inserted correctly but nothing renders because no Bot is running against the campaign.
If your data starts in a spreadsheet, there is a related question about how a sheet fits with QUE, which we cover in our page on triggering a video when a row is added. And if you are weighing QUE against reading a file directly, the overview of how QUE and Templater work together is the place to start.
So here is the bottom line. A Zap is for the person who owns the video and not the code, for a trigger Zapier already knows, and for proving an idea quickly. An API call is for the developer who owns the system the data lives in, for bulk imports, and for anyone who needs to control errors and keys. Neither is better in the abstract. Pick by who will maintain it six months from now, and build the job keys so you can change your mind.
Before you commit a team to one route, settle these.
Frequently Asked Questions
Is a Zapier Zap or an API call better for creating QUE jobs?
Neither is better in general. A Zap suits a person who does not write code and whose trigger is something Zapier can already watch. An API call suits a developer, bulk imports, or data that starts in your own application. Both create the same kind of job in a QUE campaign, so you can change your mind later without rebuilding the autograf or the campaign.
Do I need a developer to use the QUE Zapier integration?
No. Our help page describes Zapier as a no-code or low-code route for video professionals who are not necessarily developers. You need your QUE API key, a nickname for the connection, and the API URL, which is pre-filled by default. You change the URL only for a dedicated or custom QUE deployment.
Can I import a whole list of jobs at once?
Yes, through the API. The batch endpoint imports multiple jobs into a campaign in one request. You send the campaign ID and an array of job objects, and QUE returns how many jobs were added. Our Zapier page lists Insert Job and Update Job as example actions, so check Zapier’s side for anything beyond those.
Can I switch from a Zap to the API later?
Yes. Both routes write jobs into the same campaign in the same format. Replacing a Zap with an API call does not change your autograf, your campaign or your satellite. Keep your job keys simple and written down so a developer can reproduce what the Zap does. Remember to turn the old Zap off once the new route works.
What happens to my integrations if I generate a new API key?
Generating a new key invalidates the previous one. Every Zap connection and every script using the old key stops working until you update it with the new key. That applies to both routes. Store the key in one place, such as a variable or an environment setting, so you only have one update to make.
Can I use a different automation tool instead of Zapier?
Our help page says it should be possible to use any API connection or workflow automation tool to connect to QUE through its API, and that Zapier is the only first-party QUE integration for now. If you use another provider, follow its instructions for connecting to a custom API and use the QUE API reference for the endpoints.
Will creating a job make a video appear right away?
No. Creating a job puts it in the campaign with a render-status of ready. A satellite, which is a machine running Templater with the Bot enabled, has to pick the job up and render it. If jobs appear in QUE but nothing renders, check that a Bot is running and linked to the right campaign and satellite.
