Supported sources: every format and transport a supplier feed arrives in

Each supplier picks its own format and its own route

The format and the transport are the supplier's choice, not yours. One sends a CSV to an SFTP folder at 06:00. Another emails an Excel workbook from its ERP. A third publishes an XML feed at a URL, a fourth has a REST API with its own rate limit, and a fifth has only a dealer portal.

With three suppliers that is three setups. With twenty-five it is a mix of every format and transport on this page, each with its own size limits and its own way of failing. Two limits show where it bites. Excel holds at most 1,048,576 rows per worksheet, so a supplier with 1.2 million rows has to split its export over two sheets or two files. A personal Gmail account accepts attachments up to 25 MB, so a growing catalog sent by email stops arriving one day without an error on your side.

This page covers how each format and transport is read. What happens after reading (matching rows to your SKUs, which supplier wins, the checks against half-written files) is on supplier feeds, and stock from your own warehouse next to supplier stock is on stock and availability.

How it works

Every feed has a fixed definition: where the file comes from, in which format, on which schedule, and when it is expected. The integration fetches it, checks it before a single row is used, parses it into rows and hands those rows to the matching and rules.

File formats

CSV is the most common and the least consistent. RFC 4180, the closest thing CSV has to a specification, is an informational memo that describes commas and double quotes; supplier files follow their export tool. The full list of CSV and Excel problems is in supplier CSV and Excel files.

XML is cleaner but nests stock in different places. A feed with stock per warehouse:

<item sku="TW-12">
  <stock warehouse="DAL">8</stock>
  <stock warehouse="ATL">0</stock>
  <stock warehouse="RNO">6</stock>
</item>

Added up, item TW-12 has 8 + 0 + 6 = 14 units. If only the Dallas warehouse ships to you within two days, the rule counts that block alone and the store shows 8.

Fixed-width files come from older wholesale systems. They have no separators, so every field is defined by its position:

000123456TORQUE WRENCH 1/2 IN DRIVE    0001420261130
000123457TORQUE WRENCH 3/4 IN DRIVE    0000020261215

Characters 1 to 9 are the item number, 10 to 39 the description, 40 to 44 the quantity and 45 to 52 the expected date as YYYYMMDD. The first line is 14 units with a date of November 30, 2026. Read one position too far to the right, and the quantity becomes 142 and the date is seven digits long, which is why every run checks that each line is exactly 52 characters long.

Transports

SFTP is the most common route and has never become a finished standard: the SSH File Transfer Protocol exists only as an expired IETF draft, the last one being version 13. It runs over SSH, so access works with a key pair instead of a password.

A worked example: polling a feed at a URL

A supplier publishes a 30 MB CSV at a fixed URL and replaces it four times a day, at times it does not announce. Polling every 15 minutes is 96 requests a day. Downloading the full file each time is 96 times 30 MB: 2,880 MB a day, and 92 of those downloads are the same file again.

HTTP has a better way (RFC 9110). The server gives every version of the file an ETag. The integration sends the last one back in If-None-Match, and while the file is unchanged the server answers 304 Not Modified without a body. Only the 4 new versions are downloaded: 4 times 30 MB is 120 MB.

The same comparison tells the integration that nothing changed, so an unchanged file does not start a run. A supplier server that sends no ETag or Last-Modified is downloaded in full, and the file is compared with the last one by checksum.

Suppliers with no feed at all

Some suppliers have a dealer portal where you log in to check availability, and nothing else: no export, no API. There are three routes, in this order:

The browser route is the last resort. When it is used, the run checks that the screen still has the expected fields before it reads a single value, so a redesigned portal stops the run instead of producing zeros. More on all routes without an API is in integrating a system without an API.

What it covers

• Every format above, set per feed: separator, number format, encoding, worksheet, XML path, field positions.
• Every transport above, with the check that fits it: stable file size, ETag, sender, paging.
• Arrival times. Each feed has an expected time; a file that does not arrive raises an alert instead of leaving yesterday's numbers in the store.
• More than stock. Quantity, expected date or lead time, cost price, list price, discontinued flag and barcode, as described on supplier feeds. Dates are covered on delivery dates.
• One clean result for every target. The parsed rows go to the store and the ERP from the same checked run.

Where the rows go

Where standard connectors stop

Feed apps built for one store platform read many of these formats and transports, and stop at that platform: the ERP and the warehouse system get a separate import. Their schedules depend on the plan and on the transport; one documents a 15-minute schedule for FTP only, with at least an hour between runs for URLs, APIs and Google Sheets. The comparison with a Shopify feed app goes through one of them using its own documentation.

An integration built for your suppliers reads each source on its own schedule, checks it on arrival, and writes the same result to every system. A new feed runs as a dry run first. Send us a file from your most difficult supplier: tell us what you run.