# FTP Bulk Content Ingest for OTT Platforms | Vodlix **Source:** https://vodlix.com/features/ftp-uploader **Summary:** Deliver hundreds of titles by dropping files in a folder rather than through a browser, joining the same transcoding pipeline with metadata pulled in rather than typed. **Publisher:** Vodlix --- ## FTP Uploader Deliver content by dropping files in a folder rather than through a browser. The route every distributor already knows how to use. - **Feature Plan:** 2 - back-end - core-platform ## Nobody Launches a Catalogue Through a Browser A launch library arrives as hundreds of files from people who have never seen your admin area. FTP gives them a route they already understand, and gives you an ingest that does not depend on somebody watching a progress bar. ### The First Two Hundred Titles Are a Different Problem Adding a film through a web form is fine, and it stops being fine somewhere around the twentieth one. A launch catalogue is not twenty files, it is several hundred arriving from a distributor who has their own delivery process and no interest in learning yours. Browser uploads fail at ninety per cent on the largest file in the batch, they need somebody present, and they do not resume. This is the problem FTP was solving before streaming existed, which is exactly why it is still the right answer. It is unglamorous, it is universally understood by the people who deliver content for a living, and it does not care whether anybody is watching. #### A route they already use Content partners have delivered by FTP for decades. Giving them a folder needs no training, no account in your admin, and no explanation of your workflow. #### Same pipeline afterwards Files taken in this way enter the same transcoding process as anything uploaded by hand, so nothing about the catalogue differs depending on how it arrived. #### Metadata without typing Titles, artwork, cast and synopses can be pulled in rather than entered per file, which is the difference between a week of work and an afternoon. ### The Files Are the Easy Half Getting two hundred video files onto a platform is a solved problem. Getting two hundred titles, synopses, release years, cast lists, genres and pieces of artwork onto a platform is the part that actually consumes a launch, and it is where projects quietly slip by a month. A file called something like a release group name tells you almost nothing, so the useful question is not how the video arrives but how much of the description arrives with it. Pulling metadata from a catalogue source rather than typing it turns the job from data entry into review, and reviewing two hundred prefilled records is a fundamentally different task from creating them. That side is covered under [movies management](/features/movies-management), and what happens to the media itself under [video uploading and transcoding](/features/video-uploading-transcoding). ### It Is Not Only for Launch The instinct is to treat bulk ingest as a migration tool used once and then forgotten, and operators who do that end up back in a browser every week. Ongoing delivery is the more common case in practice. A distributor sends you a batch every month, a production partner delivers episodes as they finish, a syndicated feed arrives on a schedule. All of those are the same shape as the launch problem at a smaller size, and all of them are better served by a folder than by somebody being emailed a file and uploading it themselves. Because ingested content goes through the same pipeline, everything downstream behaves identically, including the publish window and territory rules described under [countdown and premiere](/features/countdown-premiere) and [conditional access](/features/cas-user-control-manager). ### Two Things Worth Getting Right The first is naming. A batch of files named consistently can be matched to metadata almost automatically, and a batch named inconsistently becomes manual work no tool can remove, so agreeing a convention with a distributor before the first delivery is worth more than any feature. The second is that an ingest folder is a door into your platform, and it should be treated like one. Separate credentials per partner, and an expectation that content appears as drafts to be reviewed rather than going live the moment it lands. Nothing published without somebody looking at it is a good rule generally and an essential one when the files came from outside your organisation. The review step itself is where [movies management](/features/movies-management) picks up. **Q: Why use FTP rather than uploading through the admin?** Because a launch catalogue is hundreds of files, not a handful. Browser uploads need somebody present, fail on the largest file in a batch, and do not resume. FTP is what the people who deliver content for a living already use. **Q: Do files delivered this way behave differently?** No. They enter the same transcoding pipeline and become the same kind of content as anything uploaded by hand, so nothing downstream differs based on how a file arrived. **Q: What about the metadata?** That is the harder half. Titles, synopses, artwork and cast can be pulled from a catalogue source rather than typed, which turns two hundred records from data entry into review. A filename alone tells you almost nothing. **Q: Is this only useful at launch?** No, and treating it that way is a common mistake. Monthly distributor batches, episodes arriving as they finish and syndicated feeds are all the same shape at smaller scale, and all of them are better served by a folder than by somebody uploading by hand. **Q: Does content go live automatically when it arrives?** It should not, and the sensible workflow has ingested content appear as drafts for review. Nothing published without a person looking at it is a good rule in general and an important one when the files came from outside your organisation. **Q: How should partners name their files?** Consistently, and it is worth agreeing the convention before the first delivery rather than after. A consistently named batch can be matched to metadata almost automatically. An inconsistent one becomes manual work that no feature can remove. **Q: Can different partners have their own access?** An ingest folder is a door into your platform and should be treated like one, with separate credentials per partner. That way access can be revoked for one relationship without disturbing any of the others. **Q: What formats can be delivered?** The same range the platform accepts elsewhere, since everything joins one pipeline after ingest. In practice the constraint is what a distributor can produce rather than what the platform will take.