The safe way to pass an asset URL into a render job is to treat the URL itself as the secret. Whoever can read the row can fetch the file, and whoever can fetch the file can keep it. If you design the link so that it is allowed to be seen by everyone who can see the data source, and so that it is still valid when the render actually runs, you avoid both leaked credentials and broken links.
This article is for the developer or technical producer who feeds product photos, logos or clips into a Templater template by URL. Picture a catalog team at an online retailer. A row for each product goes into a data source. One column holds a link to the hero image on the company’s asset server, another holds a link to a short clip. Templater downloads each file and drops it into the right layer of an After Effects template. It works in testing. In production it will meet expired links, share pages that are not files, and links that sit in a spreadsheet forty people can open.
What follows combines what our own documentation says about how Templater handles remote footage with general practice about links and credentials. We will mark where our pages stop and general advice begins, because the difference matters when it is your customers’ files at stake.
What Templater actually does with a URL
Start with the mechanism, because the failure modes follow from it. Our post on Smart URL Processing describes what happens when a data source supplies a link in place of a local file path.
Templater sees that the value is a URL for a cloud-based footage resource. It creates a folder named [TEMPLATER DOWNLOADS] inside your footage source directory and downloads the file into it. From there the file is treated like any other footage in the project. You do not need to download and import it by hand, and the project stays current with whatever the link currently points at.
Links come in two flavors, and the difference decides how easily things break. A direct download link names the file and its extension. A share link is the kind a cloud storage product gives you to send to a person, and it often points to a web page that then offers the file. With the version of Templater described in that post, share links are handled too. The software gives the downloaded file a random hash as its name at first and then works out what it is. After the download, Templater checks the MIME type, the standard label for a file’s kind, and confirms the type is compatible with After Effects. If it is, Templater attaches the right extension. If it is not, Templater logs a detailed error.
Our own example of that last case is a download from a cloud drive that returns an HTML page instead of the video, which can happen because of virus scanning on large files. This is the most important thing to understand about URLs in render jobs. The request succeeded. A file arrived. It was simply the wrong file. A link can be perfectly reachable and still not be an asset.
So we recommend direct download links where you can get them, particularly for large files and for certain cloud drives, because they avoid the incomplete or substituted downloads that share links can produce. We also suggest checking regularly that the types of files you link are ones After Effects supports, and keeping an eye on the [TEMPLATER DOWNLOADS] folder, both to manage storage and to see what has arrived.
One more mechanism is worth keeping in view. After Effects itself will fail a queue item with “Failed at N/A” when it cannot find an asset, footage file or font in the location the project expects. That is the render side of the same problem. If a downloaded file is moved or deleted between the download and the render, you get this error even though the link was fine. So the folder Templater downloads into is part of your system, not a scratch area to tidy up casually.
Keeping credentials out of the link
This is where general practice takes over, because our pages do not describe a way to send login details or custom headers with a download request. We are not going to suggest that Templater can do something we have not documented. What we can say is how to think about a link that has to be used by a tool that only knows how to ask for it.
A URL in a data source is a capability. Anyone who holds it can use it. That is true of every link, and it matters more here because data sources are read by many things. A Google Sheet has collaborators. A JSON feed is fetched by whatever calls it. A job in QUE is visible to the people with access to the campaign. Templater and its logs may write the link down. Our data source options are spreadsheets, tab-separated files, JSON files and feeds, and QUE, and in every one of them somebody other than the render machine can see the value.
So begin from a simple test. Would you be comfortable if every person who can open this row could also download this file? If the answer is yes, the link can go in the row as it is. Product photos on a public content delivery network usually pass this test, because they are already on the public web and the link reveals nothing that the storefront does not.
If the answer is no, you have a few honest options. None of them involves putting a username and password inside a URL, which is the one thing to avoid. Credentials in the address end up in logs, in spreadsheets, in browser history and in screenshots, and they are very hard to take back.
The first option is a link that carries its own temporary permission. Many storage services can generate a signed address that grants access to one file for a limited time and then stops working. The credential is in effect the link, and it expires on its own. If a signed link leaks, the damage is bounded by its lifetime. The catch, which we will come to in a moment, is that the lifetime has to outlast the wait before your render runs.
The second option is to move the file instead of exposing it. Have your own application copy the asset to a location Templater can reach, with access you control, and put that location in the row. This is more work and it is the right answer when the source is sensitive and cannot be given a temporary link. Remember that with Projector, rendering happens on your own machine, and our pages say your assets are not visible to another party, so the sensitive part of the chain is the part before the render, where the file moves.
The third option is to keep the secret out of the data source altogether. If a row needs to say “use the logo for this account,” put an identifier in the row, not a link. Let your own application, which does hold the credentials, resolve the identifier into the right file at the moment the job is created. That keeps the spreadsheet or the job record free of anything worth stealing. It also gives you one place to change when storage moves.
A word about who reads what. When you design for the people who can see a data source, include the people who inherit it. A sheet that begins with three trusted editors tends to be shared with a vendor, then with a freelancer, then copied into a new workbook that has different sharing settings. Links outlive the intentions of the person who pasted them. That is one more reason to prefer links that expire and identifiers that mean nothing outside your own system. A rule you can enforce in the link beats a rule you have to remember to repeat.
On the QUE side, our documentation says data is protected with end-to-end encryption and field-level masking where appropriate, and the API uses an API key and an organization key. Those keys belong on your server. Do not place them in a template, in a data row or in a page that a customer’s browser loads. The keys decide who can create jobs. The asset links decide who can read files. Keep the two kinds of secret separate, so that exposing one does not expose the other.
Keeping links from breaking before the render runs
A link can be safe and still fail, and the usual cause is time. The data is written at one moment and the render happens at another. In between, things change.
Lifetime is the first cause. Suppose you use signed links that last a short while. The job is created, and it waits in a queue behind other jobs. Maybe it fails and is retried later. By the time After Effects is ready for it, the link has expired, and the render fails on a file that was valid when you wrote the row. Our documentation gives no figures for how long a job waits, because it depends on your machines and your batch, and we are not going to invent one. What you should do is measure the longest realistic wait in your own system, including retries, and set link lifetime comfortably beyond it. If you cannot predict the wait, generate the link as late as you can, which means creating the job at the time you mint the link.
Replacement is the second cause. Someone uploads a corrected image over the old one, and the link now serves something different from what the row’s author expected. Or someone deletes a file because it looked unused. For anything that goes into a finished video, prefer addresses that do not change in meaning. Put a version or a date in the path, add the new file next to the old one, and never overwrite. Then a link in an old row still means what it meant, and a video you re-render next month looks like the one from last month.
Formatting is the third cause, and the dullest. Spaces and unusual characters in file names, a link pasted with trailing text from an email, a path copied with a line break. These create URLs that look right and do not work. Normalize links before they go in the row, and reject anything that does not look like a link at the front door, where you can tell a person right away.
The fourth cause is the page that is not a file. We described it above. The way to catch it before it costs you a render is to do what Templater does, earlier. When your application receives a link, fetch it, look at the type of file it returns and confirm that it is the kind of thing you expect. An image link should return an image. A clip link should return a video. If the link returns a web page, tell the sender then, not after a batch has run. This is the same MIME-type idea our own software applies at download time, moved to the point where someone can still fix it cheaply.
It also helps to decide in advance what a failed link should do to the job. There are two bad answers. One is to render anyway with a blank layer, which produces a finished video that looks wrong and is delivered as if it were right. The other is to retry again and again against a file that is never going to arrive. The better answer is to stop that job, record which link failed and why, and let a person supply a good one. If a template has an optional layer, say so in the rigging and in the data, using something deliberate such as the off flag our documentation describes for hiding a layer, so that a missing image is a decision and not an accident.
Let us return to the catalog team. Their asset server sits on the public web, and the hero images are already shown on the storefront, so those links go into the data source untouched. The clips are different. They are unreleased campaign footage kept in private storage. For those, the team’s application creates the job and only then asks storage for a link that stays valid well past their longest observed queue, and it checks that the link returns a video before the row is written. A reviewer who opens the spreadsheet sees links that expire on their own and nothing else. When a link does fail, the job is parked with the reason, and nobody lost an afternoon looking for it.
The result that matters for the finished video is also worth stating. Once Templater has downloaded a file and rendered the video, the output contains the media. It does not depend on the link staying alive. So the link needs to work for the length of the job, not forever, and that is a much easier thing to guarantee.
Finally, test the real path before you scale. Send one job with a link of each kind you plan to use, a public link, a signed link and a link you know is broken, and see what Templater logs for each. Our learning section has material on Templater workflows if you want to check how the other parts fit together. Do it with the same data source and the same machine you will use in production, because a test on your laptop with a local file proves nothing about links.
The bottom line is short. Assume anyone who can read the row can use the link. Put in the row only what you could stand to have shown, use links that expire on their own, and keep the key to your own system on your own server. Then make sure each link is the right kind of thing before the job is created, and stays valid longer than the longest wait. Credentials leak through carelessness about where a link lives. Links break through time. Design for both and the render only has to do its job.
Links and credentials raise the same questions in almost every project we see. Here are the ones to settle before you scale a batch.
Frequently Asked Questions
How does Templater use a URL from my data source?
When a data source supplies a URL for a cloud-based footage resource, Templater creates a [TEMPLATER DOWNLOADS] folder inside your footage source directory and downloads the file there. It then checks the MIME type and, if After Effects can use the file, attaches the matching extension. If the type is not supported, Templater logs a detailed error instead of using the file.
Why did my link work in a browser but fail in a render?
A link can be reachable and still not be the file. Large files on some cloud drives return a web page about virus scanning instead of the footage. A browser shows you that page and lets you click through, while Templater downloads the page itself and reports the wrong file type. A direct download link avoids this problem, so use one wherever the source allows it.
Can I put a username and password in the URL?
Avoid it. Credentials inside an address end up in spreadsheets, logs, screenshots and browser history, and they are hard to withdraw. Use a link that carries its own temporary permission, copy the file to a location you control, or put an identifier in the row and let your own server resolve it to the right file when the job is created.
Does Templater send login headers with a download request?
Our public pages do not describe that, so we do not claim it. If an asset sits behind a login, give Templater a link that works on its own, such as a time-limited signed address, or move the file to storage that it can reach. Test a real job with that kind of link before relying on it.
How long should a signed link last?
Longer than the longest wait a job will realistically have, including queue time and any retries. We cannot give you a figure, because it depends on your machines and your batch. Measure your own worst case, then set the lifetime beyond it. If waits are unpredictable, create the job and mint the link at the same moment.
Does the finished video depend on the link staying alive?
No. Once Templater has downloaded the file and After Effects has rendered the video, the output contains the media. The link needs to work for the length of the job, not forever. Keep the files in [TEMPLATER DOWNLOADS] in place until the render finishes, because moving them can cause a “Failed at N/A” error.
