Reliable Tools for Large Nightly FTP Batches to Stock Agencies

Which tools survive a multi-thousand-file overnight FTP run to several stock agencies, and what the agencies' own docs say about limits and retries.

An overnight batch of a few thousand files fails for boring reasons: a dropped connection at three in the morning, an agency that quietly discards a half-written file, a queue with no retry and no record of what got through. The tools that survive a run like that all share three traits — they upload in the background, they keep a history, and they let you re-send only what failed.

What actually breaks in an overnight run

Very little goes wrong with a ten-file upload. The failure modes only appear at volume, and they are rarely dramatic. A laptop sleeps mid-transfer. A router renegotiates its connection. An agency's ingestion queue is busy and the session times out. The transfer itself is not the fragile part — the fragile part is knowing, the next morning, exactly which files landed and which did not.

That is why upload history matters more than raw transfer speed. A tool that moves files fast but cannot tell you what it moved forces you to reconcile a folder against six agency dashboards by hand, which is exactly the work you were trying to avoid. Practically, the things that go wrong in a large nightly batch fall into four groups:

What the agencies themselves document

Most advice about overnight uploads is folklore. The agencies publish less than people assume, and where they do publish, the details differ enough to matter when you are running one job across several destinations. Here is what their own contributor documentation states.

Shutterstock

Shutterstock's contributor help documents FTP over TLS on port 21 at ftps.shutterstock.com, and states that uploaded files can take up to 72 hours to appear on the site. That single number changes how you should read an empty dashboard the morning after a run — nothing appearing is not evidence of failure. Their FTPS upload article also carries an ordering rule that trips up scripted workflows: do not send the CSV alongside the media over FTPS. It has to be attached separately on the Submit page.

Adobe Stock

Adobe states plainly that you can upload as many files as you want and that there are no data limits, and FTP credentials are generated per account inside the Contributor portal rather than published as a fixed host. On interrupted transfers, Adobe's guidance is reassuring and specific: files that have already uploaded successfully are available in the portal, and you can continue with the rest once you reconnect. The browser upload path carries a 45 MB per-file ceiling, which is the usual reason people move to FTP for video in the first place.

Alamy

Alamy documents plain FTP on port 21 at upload.alamy.com. Their contributor upload guide states that the very first submission must be exactly three images and that after that there are no limits, that images go on sale within 24 hours on average once they clear QC, and that submissions cannot be deleted while they are queued for QC. The detail that breaks automated runs is the destination folder: Live News, Stock, Archive stock and Vectors are separate, and vector files need an accompanying JPEG carrying the IPTC caption and keywords under a matching filename in the same batch.

Pond5, Depositphotos and 123RF

Pond5 uses ftp.pond5.com and requires a dedicated FTP password of at least eight characters that must differ from your login password — set separately under Account. Their FTP uploader documentation asks you to allow at least a few hours for files to appear on the Uploads page, and a system-level rejection surfaces there as "Processing Failed" rather than as a transfer error, so a clean transfer log does not mean a clean batch.

Depositphotos is the most permissive of the three on paper: it uses ftp.depositphotos.com and states outright that there are no restrictions or limitations on the number of images you can upload per day or on the frequency. 123RF splits by content type — ftp.123rf.com for stills and footage.ftp.123rf.com for video — and publishes hard technical ceilings: photos up to 30 MB and at least 6 megapixels at 80% JPEG quality or better, video up to 4 GB, up to 120 seconds, at 720p or above.

123RF also has a two-step ingestion that catches people out: transferring the files is not the end of it, because the batch has to be pulled in from the Contributor Dashboard under Upload Content before it enters the processing queue. An unattended script that finishes its transfer and exits will leave that batch sitting untouched until someone logs in.

One thing worth stating plainly, because it is repeated so often as fact: none of these agencies publishes a recommended off-peak upload window. Advice about uploading at 4am to catch an idle queue is third-party guesswork. What the agencies do publish is ingestion time — up to 72 hours at Shutterstock, roughly 24 hours to on-sale at Alamy, a few hours at Pond5 — and those figures are the ones worth planning around.

Six tools, and what each is actually good at

These are the options contributors realistically choose between for large recurring batches. None of them is best at everything, and the honest differences are mostly about where the work runs and who holds the credentials.

A scripted FTP client (lftp, rclone, FileZilla)

Xpiks

StockSubmitter

Microstock+

Managed distribution services

Rastock AI

When to use which

Use a scripted FTP client when your metadata is already correct and embedded, your destinations are few, and what you actually need is a transfer that retries by itself and writes a log. This is the strongest option for a single high-volume destination and the weakest for six destinations with different field rules.

Use Xpiks when you work on one machine, prefer a one-time purchase to a subscription, and want fine manual control of keywords. Use StockSubmitter when destination breadth is the deciding factor and you are on Windows; use Microstock+ instead when you are not on Windows, or when you want the batch to keep running with your laptop shut.

Use a managed service when you would genuinely rather not think about any of this and the royalty share is acceptable to you. Use a metadata-and-delivery platform like Rastock when the nightly batch is large, the destinations differ in what they will accept, and the failure you keep hitting is metadata rejection rather than transfer failure — those are different problems and they need different tools.

A checklist for the night before

For the per-agency mechanics, we have step-by-step walkthroughs for uploading to Shutterstock via FTP and uploading to Adobe Stock via FTP, both of which cover the folder conventions a scripted run has to respect.

If you are designing the pipeline rather than fixing one run, our explainer on automatic upload to multiple stock agencies covers the architecture, and avoiding duplicate uploads across agencies covers the failure mode that a retry-happy nightly job tends to create.

Frequently asked questions

Is there a best time of night to run a large FTP batch?

None of the major agencies publishes a recommended off-peak window, so any specific hour you see quoted is third-party guesswork. What they do publish is ingestion time. Shutterstock says files can take up to 72 hours to appear, Alamy says images go on sale within roughly 24 hours after QC, and Pond5 asks for at least a few hours. Plan around those windows rather than around a supposed quiet hour.

My files transferred but nothing shows in the dashboard. Did the run fail?

Probably not. Ingestion is a separate stage from transfer at every major agency, and the published delays are long enough that an empty dashboard the next morning is normal. 123RF is the exception worth checking first: after the FTP transfer you have to pull the batch in from the Contributor Dashboard before it enters processing at all, so an unattended script leaves it sitting.

Can I send my metadata CSV over FTP with the images?

It depends on the agency, and Shutterstock explicitly says no. Their help documentation instructs contributors not to upload the CSV with the media over FTPS or the web uploader, and to attach it separately on the Submit page instead. Adobe also handles CSV through the Contributor portal rather than the FTP drop. Check each destination before scripting a single combined transfer.

Do I need SFTP rather than plain FTP?

Where an agency offers it, encrypted transfer is the safer default, but you do not always get the choice. Shutterstock documents explicit FTP over TLS on port 21, while Alamy and several others document plain FTP. Since the agency defines what its server accepts, the practical rule is to use the most secure option each destination publishes rather than to standardise on one protocol.

What happens to a file if the connection drops mid-transfer?

It usually leaves a truncated file that then fails review for reasons unrelated to the image. Adobe states that files already uploaded successfully remain available in the portal and that you can continue with the remainder after reconnecting. Most other agencies do not document resume behaviour, which is the strongest practical argument for a tool that keeps an upload history and can re-send only the incomplete files.

Is a free scripted FTP client good enough for a nightly batch?

For pure transfer reliability, yes, and often better than paid tools: lftp or rclone will retry, parallelise and log without complaint. What a script cannot do is handle per-agency metadata rules, Alamy's paired vector JPEGs, or the reconciliation afterwards. If your failures are transfer failures, a script solves them. If your failures are metadata rejections, it will not.