An embedded CSV importer is a widget inside your app: a customer uploads a spreadsheet, matches columns, fixes errors on screen and submits. An automated file ingestion platform has no customer on the screen: files arrive on their own over SFTP or by email, on a schedule, and the platform maps, validates and delivers them without anyone clicking. If your customers upload a file once during onboarding, you need an importer. If their systems send you a file every night or every pay period, or your team processes files on the customer's behalf, you need an ingestion platform. Many B2B products end up needing both, for different moments.
To see the ingestion side on your own data, drop one real client file here and watch it get mapped and validated in the browser, with no account.
Key Takeaways
- The deciding question is not the file format. It is who is present when the file arrives: a customer at a screen, or nobody.
- Embedded importers solve self serve, one time uploads. They do not watch an SFTP folder, read an inbox or run at 2am.
- Ingestion platforms solve recurring feeds and files your team handles for the customer. They need a mapping per sender, validation on every run and a run history, not a nicer upload screen.
The real difference: who opens the file
Both categories parse files, map columns and validate rows, so on a feature list they look alike. The difference is the operating model around those steps.
Embedded CSV importer
A component you put in your frontend. The customer is the operator: they pick the file, confirm the column matches the importer suggests, correct the rows it flags, and press submit. Your backend receives clean records. It works well for first time setup (import your contacts, your products, your employee list) and for occasional bulk edits. It assumes a person with the file is in front of your app, and the moment they close the tab the import is over.
Automated file ingestion platform
A backend service with no customer facing screen during a run. Files arrive over SFTP or as email attachments, produced by the customer's HRIS, ERP, payroll or inventory system on a schedule. The mapping for each sender is set up once, usually by your implementation team, and every later file runs through it automatically: parse, map, validate, deliver, log. People only get involved when a file fails, and they see exactly which rows and why.
A useful test: if the honest answer to "who fixes a bad row?" is "the customer, right now, in our app", you want an importer. If it is "our onboarding team, tomorrow morning" or "nobody, it should just work", you want an ingestion platform.
Side by side
Importer: a person uploads in your app. Ingestion platform: SFTP drop or email attachment from the customer's system, on their schedule.
Importer: the customer, every upload, with suggestions. Ingestion platform: your team once per sender, then reused for every file.
Importer: the customer on screen before submit. Ingestion platform: a row level error report to your team or the customer, then reprocess.
Importer: one time or occasional. Ingestion platform: daily, weekly, per pay period, indefinitely.
Importer: a frontend component in your product. Ingestion platform: a backend service with its own run history.
Importer: a UI project. Ingestion platform: SFTP or inbox handling, a scheduler or watcher, per client mappings, retries and monitoring.
Headless importers: the middle option
Several importer vendors also sell a headless mode: the same mapping and validation engine called through an API, with no widget. That gets you closer to automation, but the parts that make recurring files hard are still yours. Your code has to collect the file from the SFTP folder or the inbox, decide which customer and which mapping it belongs to, call the API, store the result, retry when something fails and tell someone when a file did not arrive. A headless importer is an engine. An ingestion platform is the engine plus the plumbing around it.
Dromo vs a headless ingestion platform for files arriving by email and SFTP
This is the comparison buyers ask about most often. Dromo is a well built embedded importer with a developer friendly SDK, and its headless option runs the same engine server side. If your files arrive by email and SFTP, the questions to ask any vendor, Dromo included, are the same: does it host the SFTP endpoint or connect to the customer's server, does it give each customer an inbox address, does it pick files up by itself, does it keep a mapping per sender, and does it keep a run history you can reprocess from. If the answer is "your code does that", you are buying an engine and building the platform around it. Our Dromo comparison goes through it point by point.
Which one you need
- Self serve onboarding, one upload per customer: an embedded importer. FileFeed's embeddable importer is free with unlimited end users if you want to start there.
- Enterprise customers whose systems export on a schedule: an ingestion platform. The customer's IT will not build to your API, but they will point a scheduled export at an SFTP folder.
- Your team receives spreadsheets by email and re keys or cleans them: an ingestion platform. This is processing files on the customer's behalf, and an importer only moves the manual work to a nicer screen.
- Both: common in HR, benefits, retail and supply chain software. Smaller customers self serve through the importer, larger ones send a nightly file. Keep one target schema so both paths deliver the same records.
What to check before you sign
- Run one real customer file through it, not a sample made for the demo. Real exports have merged headers, odd date formats and trailing totals rows.
- Ask how a second file from the same customer is handled. If it needs a human to map it again, it is an importer, whatever the page says.
- Ask what happens when the customer renames a column. The right answer is a clear validation failure and a reprocess after the mapping is fixed, not silently empty fields.
- Ask how delivery works: webhook, API, or a push to your own SFTP, and whether you can see every run afterwards.
- Ask how long until the first customer is live, and what happens if it takes longer.
For a wider view of the market, including file transfer tools and the recurring feed products, see data onboarding tools compared. For the API question that usually comes up next, see file based integration vs API.
Frequently asked questions
What is the difference between an embedded CSV importer and a file ingestion platform?
An embedded CSV importer is an upload screen inside your product where the customer maps and fixes their own file. A file ingestion platform receives files automatically over SFTP or email and processes them with a saved mapping per sender, with no one on screen. The first is for one time, self serve uploads. The second is for recurring files and files your team handles for customers.
Are there Flatfile alternatives for recurring customer files, not just an in app upload widget?
Yes. Flatfile, now Obvious, built its name on the in app importer. For recurring files you want a product built around SFTP and email intake, per customer mappings and run history. FileFeed's Automated FileFeeds and OneSchema's FileFeeds are both in that group. The Flatfile comparison covers the details.
What should teams that process files on the customer's behalf use?
An ingestion platform, not an importer. When your onboarding or operations team is the one receiving and cleaning customer spreadsheets, the goal is to stop opening the file at all: map each customer's layout once, validate every file automatically and only look at the rows that fail. Importers such as CSVbox or the OneSchema importer are designed for the customer to do the work in your app.
What are the best tools for automating CSV and XML ingestion from customer systems?
Look for four things: intake that does not need a person (hosted SFTP, the customer's SFTP server, or an inbox per customer), a mapping saved per sender, row level validation with an error report, and delivery to your system through a webhook or API with a full run history. FileFeed parses CSV, JSON and XML files received over SFTP and email this way. Managed file transfer tools move the file but leave mapping and validation to you.
Can we use an importer and an ingestion platform together?
Yes, and many B2B products should. Point both at the same target schema. Small customers upload through the importer in your app, larger customers send a scheduled file, and your backend receives the same validated records either way.
Try it on one real file
The fastest way to know which side you are on is to take the file your customers actually send. Drop it into the browser demo, or send it for the free 48 hour file check and get it back mapped to your schema with the rows that would fail. When you are ready to run it on the customer's schedule, the Feed Pilot puts the first feed live within 30 days or you get the money back.
Related resources