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 (scheduled replacements) | Good | Excellent | Good between systems that both speak it — not offered by InventaCloud |
| Authentication | None in the file itself | Portal session or API key | Scoped API keys | Server credentials (n/a here) |
| Update frequency | Per file sent | Per fetch | Per request | Per delivery |
| 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.
InventaCloud does not use FTP. There is no drop folder to deliver into and no FTP feed for resellers. Catalog, inventory, price, and discontinued files upload directly from your computer (a newer file can be queued as a scheduled replacement); images arrive as folders, ZIPs, a spreadsheet of links, or a direct upload inbox; and on the way out, Excel or JSON downloads and the API cover what an FTP feed would have. If a system you work with only speaks FTP, export its file and upload it.
7. File format versus delivery method
Format and delivery are separate decisions. The same CSV can be emailed to you by a supplier, exported from an ERP, or pulled from a partner portal — the format didn't change, the transport did. Into InventaCloud, the transport is always a direct upload.
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 | — (not offered; upload the file directly) | — (not offered; use downloads or the API) |
Supported directions depend on the customer plan and current integration availability.
9. Full replacement versus incremental updates
File-based workflows (CSV, uploaded directly) 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 — not offered; there are no FTP credentials to issue or protect.
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 on its own rhythm, you upload the file (or queue a newer one as a scheduled replacement), and processing runs in the background. 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 regular exports want file uploads; 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.
Two systems you control both speak FTP and neither has an API — a fine transport between them. InventaCloud itself does not use FTP; the file it produces uploads directly.
Practical scenarios: A supplier emailing a monthly spreadsheet → CSV upload (queue scheduled replacements 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 → CSV upload, with the next file queued as a scheduled replacement. (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.
It doesn't — there is no folder to deliver into. Export the file and upload it, or queue it as a scheduled replacement.
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.
Can I send files to InventaCloud over FTP?
No — InventaCloud does not accept files over FTP or SFTP, and does not deliver over them. Upload CSV or XLS/XLSX files directly (a newer file can be queued to replace the current one at a set time); resellers use Excel or JSON downloads or the API.
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. Queue scheduled replacements when a regular rhythm makes hands-off timing 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.