CSV vs JSON vs API vs FTP: choosing the right product feed
These four names get used interchangeably, and they shouldn't be — two are data formats, one is an application interface, and one is a way of moving files. Picking the right combination is easier once the categories are clear. This guide explains what each one actually is, which directions each supports in InventaCloud today, and how to choose for your situation.
1. First, untangle the words
The most common feed confusion is comparing things from different categories:
- CSV is a tabular file format — rows and columns, like a spreadsheet saved as text.
- JSON is a structured data format — nested keys and values that systems parse.
- API is a request-based application interface — a system asks for data and gets a response. It is not simply a downloadable file.
- FTP is a file-transfer method — a way of moving files, which may carry CSV or other supported files. FTP is not itself a product-data format.
So "CSV vs FTP" isn't really a versus — a CSV file can travel over FTP. The real decisions are: what format does the consuming side need, and how should the data move?
2. Quick comparison
| CSV | JSON | API | FTP | |
|---|---|---|---|---|
| What it is | Tabular file format | Structured data format | Request-based interface | File-transfer method |
| Human readability | High (opens in Excel) | Moderate | Low (responses are for systems) | n/a — carries files |
| Machine readability | Good | Excellent | Excellent | Depends on the file carried |
| Typical size | Compact | Larger than CSV for the same data | Per-request payloads | Whatever the file is |
| Nested data | Poor (flat rows) | Excellent | Excellent | Depends on the file |
| Spreadsheet editing | Excellent | Poor | n/a | n/a |
| Automation potential | Good (esp. via FTP) | Good | Excellent | Good, where configured |
| Authentication | None in the file itself | Portal session or API key | Scoped API keys | Per-workspace credentials |
| Update frequency | Per file sent | Per fetch | Per request | Per delivery + ingestion schedule |
| Incremental updates | Good (partial files) | Consumer pulls current state | Consumer pulls current state | Good (partial files) |
| Technical complexity | Lowest | Low-moderate | Moderate (developer needed) | Low (IT familiarity) |
| Typical use | Supplier files, partner downloads | Storefronts, middleware | Automated system syncs | Recurring file workflows |
None of these is universally best — they solve different problems, and most real operations use two or three together.
3. What is a CSV product feed?
A CSV feed is product data as rows and columns — one product per row, one field per column. It's the lingua franca of product data because everything reads it: spreadsheets, ERPs, store platforms, and people.
In InventaCloud, spreadsheet formats are primarily the import side: vendor CSV and XLS/XLSX files import through the AI mapping and validation workflow (suggestions require your review — not every column maps itself). On the delivery side, reseller catalog downloads come as Excel (.xlsx) or JSON, and reseller inventory exports as CSV, Excel, or JSON. Details on the CSV integration page.
4. What is a JSON product feed?
A JSON feed is the same catalog as structured data — named fields, proper types, and support for nesting — which is what custom storefronts, apps, and middleware want to consume. Where a CSV is for opening, a JSON feed is for parsing.
In InventaCloud, JSON is a delivery format: approved consumers pull published catalogs as JSON — shaped by each catalog's rules — on demand from the portal or programmatically. JSON files are not uploaded through the catalog-import workflow; imports use CSV and XLS/XLSX. Details on the JSON integration page.
5. What is a product catalog API?
An API isn't a file at all — it's an interface your systems call: "list the catalogs this key can access," "give me the current product rows." The response reflects the live published catalog at the moment of the request, which is why APIs suit automated syncing.
InventaCloud's current public API scope is read and delivery: scoped, revocable API keys that list approved catalogs and fetch product rows (pricing, inventory, images, status) over HTTPS. The documentation is the source of truth for what a key can do. Details on the API integration page.
6. What is FTP product-feed delivery?
FTP moves files between systems — it's the transport, not the cargo. An "FTP feed" almost always means "CSV (or similar) files delivered over FTP," which is how ERPs and warehouse systems have shared data for decades.
In InventaCloud, each workspace gets dedicated FTP credentials. Catalog and inventory files delivered to your drop folder enter the same import workflow as uploads — mapping, validation, error reporting — and automated processing is available once your ingestion schedule is configured; folders aren't continuously monitored by default. FTP also carries bulk image uploads and feed delivery where configured. Details on the FTP integration page.
7. File format versus delivery method
Format and delivery are separate decisions. The same CSV can be uploaded by hand this month and delivered through a configured FTP workflow next month — the format didn't change, the transport did.
8. Import versus export direction
Each method's verified directions in InventaCloud today:
| Method | Into InventaCloud (import) | Out of InventaCloud (delivery/export) |
|---|---|---|
| CSV (and XLS/XLSX) | Yes — the catalog-import workflow | Excel (.xlsx) reseller catalog downloads; CSV for reseller inventory exports |
| JSON | — | Yes — portal downloads and programmatic access |
| API | — | Yes — current verified read/delivery scope |
| FTP | Yes — file delivery into the configured import workflow | Yes — feed delivery where configured |
Supported directions depend on the customer plan, configured workflow, and current integration availability.
9. Full replacement versus incremental updates
File-based workflows (CSV, via upload or FTP) support both patterns: send the full catalog and change detection works out what's new, changed, or discontinued — or send partial update files (prices, inventory) that touch only the SKUs listed.
Pull-based consumers (JSON, API) don't think in updates at all — every fetch returns the current published state, so "incremental" happens on the consumer's side by comparing or simply replacing what they hold.
10. Authentication and access
- CSV downloads — the reseller's authenticated portal session; each partner only ever sees their approved, rule-applied catalog.
- JSON — portal session or scoped API key, same per-partner scoping.
- API — scoped API keys issued per workspace, revocable instantly, HTTPS only.
- FTP — dedicated per-workspace credentials, scoped to your own folders, rotatable and revocable.
11. Error handling and validation
Inbound files — however they arrive — pass the same validation: field standards and import rules check every row, valid rows import, and problems land in a per-row error report naming the field at fault. Automation never means unreviewed data.
On the outbound side, API errors are explicit (bad key, unknown catalog, unauthorized scope), and generated downloads come from the validated published catalog — the error handling happened before delivery.
12. Scheduling and automation considerations
Automation looks different per method. File workflows automate on the producer's schedule: your ERP exports nightly, delivers via FTP, and processing runs per the ingestion schedule configured for your workspace. Pull workflows automate on the consumer's schedule: their system fetches JSON or calls the API whenever it wants current data.
The practical rule: automate the side that owns the rhythm. Suppliers with nightly exports want file delivery; storefronts that need current data at page-build time want pull access.
13. How to choose the right approach
Humans are in the loop — suppliers exporting from ERPs, buyers reviewing in Excel, partners importing into standard tools. It's the lowest-friction common ground.
A system is consuming — custom storefronts, apps, middleware — and structured, typed, nestable data beats parsing a spreadsheet.
You need current data on demand and have a developer — automated syncs that ask for exactly what they need, when they need it.
Files already flow on a rhythm — legacy ERPs, warehouse exports, bulk images — and the producing system speaks files, not APIs.
Practical scenarios: A supplier emailing a monthly spreadsheet → CSV upload (move to FTP delivery when the rhythm stabilizes). A distributor publishing structured data to partner systems → JSON delivery. A reseller's storefront requesting current catalog data → API access. A manufacturer's ERP producing recurring exports → FTP delivery into a configured ingestion workflow. (Companies here are illustrative — e.g. "Demo Supply Co." sending DEMO-00123.)
14. Common implementation mistakes
"Send us an FTP" means nothing until you agree what file travels over it. Decide the format first, the transport second.
An API returns responses to requests — if a partner wants "a file to download," give them CSV or JSON delivery instead.
FTP-delivered files enter the import workflow, and automated processing needs your ingestion schedule configured — confirm the configuration before relying on it.
If the consumer needs multi-value, nested structures, CSV fights you — that's what JSON delivery is for.
15. Practical decision checklist
- Who consumes the data — a person, a spreadsheet tool, or a system?
- Does the data need nesting, or is it happy in rows and columns?
- Who owns the update rhythm — the producer (files) or the consumer (pull)?
- Is there a developer available, or should this stay file-based?
- Full refreshes, partial updates, or on-demand current state?
- What does your partner's system actually accept? (Ask — don't assume.)
- Which directions and workflows does your plan and configuration support today?
Common questions
Can I import JSON files into my catalog?
Not through the current catalog-import workflow — imports use CSV and XLS/XLSX files. JSON is a delivery format: approved consumers pull your published catalog as JSON. If your source data is JSON today, converting to CSV for import is the reliable path.
Is the API faster than downloading files?
They serve different needs rather than racing. Both reflect your current published catalog; the API suits systems that want to ask for data programmatically, while downloads suit people and tools that want a file.
Does FTP mean my files process automatically?
FTP-delivered files enter the same import workflow as uploads, and automated processing is available once your workspace's ingestion schedule is configured — it's a configured workflow, not default continuous folder monitoring.
Which one should a small vendor start with?
CSV upload — it works with the files you already have, and the AI mapping workflow does the heavy lifting on the first import. Add FTP delivery when a regular rhythm makes hands-off transfer worthwhile.
Whatever the format, the catalog is the easy part.
Start a 14-day free trial — import a CSV today, and add delivery formats as your partners need them.