XML Product Feed and Supplier Integration: CSV or API for Your Online Store

Integrating with a wholesaler, in practice, means synchronizing two different things that change at completely different speeds. The catalogue — names, descriptions, photos, categories — changes rarely, sometimes once a week or less. Stock levels and prices change often: hourly for some wholesalers, in real time for others. Whether you end up using a CSV file, an XML product feed, or an API isn't a question of which technology happens to be fashionable — it follows directly from how often the data actually changes and how fast you need to react to that change.

What you're actually synchronizing with a wholesaler

Separating the catalogue from stock-and-price has a concrete consequence for the format you choose: a file you update once a week can be a manually uploaded CSV with no automation at all. Data that has to be current within minutes — stock for a product that's about to sell out, a price at a wholesaler that updates its price lists several times a day — needs a recurring mechanism or an API, because uploading a file by hand once a day guarantees that for part of the day you're selling stock the wholesaler no longer has, or at a price that no longer applies.

In practice, "catalogue" covers the product name, description, photos, category and attributes (colour, size, material) — fields that only change when the wholesaler launches a new product or fixes an error in a description. "Stock and price" covers the available quantity and the purchase price (or the recommended retail price, if the wholesaler suggests one) — fields that can change several times within a single day, independently of whether the product itself changed at all.

The practical consequence of this split: you don't have to — and usually shouldn't — build one uniform integration for both kinds of data. You can import the catalogue through one mechanism (a weekly CSV, say) and sync stock and price through a completely different, more frequent one (an XML feed refreshed hourly, or a real-time API). Mixing both into a single, rarely-run import job is one of the most common reasons a store's stock drifts away from what the wholesaler actually has — not because the mechanism is broken, but because data that changes at two different speeds ended up on the same, single schedule.

CSV — the simplest format, with one myth to retire

CSV is the least technically demanding format — every shop platform supports it, and a wholesaler can export one from its own system without a dedicated integration.

Shopify. Shopify's documentation describes the file's formal requirements without stating a size limit: "save your CSV file in UTF-8 format using LF-style linefeeds," and every column must be comma-separated, with the first row as column headers (help.shopify.com/en/manual/products/import-export/using-csv, read 2026-10-01). Images aren't part of the file itself — "A CSV file can only contain text," and elsewhere on the same page: "You can use only image URLs in CSV files." Image URLs from external sources have to be publicly accessible, served over https:// and not password-protected. None of the three Shopify documentation pages checked — the CSV import page, the import/export overview, and the troubleshooting page — states a maximum file size in megabytes. If you've heard of a 15 MB limit, that figure has no support in current Shopify documentation; the only confirmed, specific limit applies to stores with at least 500,000 variants (Shopify Plus stores excluded), which can create at most 10,000 new variants per 24 hours through CSV uploads or the API.

WooCommerce. WooCommerce's built-in product CSV importer has no size limit of its own — "The Maximum size value shown on the upload screen is set at the server level. To increase it, contact your hosting company" (woocommerce.com/document/product-csv-importer-exporter, read 2026-10-01). If an import fails because of file size, the documentation's advice is to split the CSV into smaller batches and import them separately — you can only raise the limit through your hosting provider. The only required columns are SKU (WooCommerce generates its own if omitted) and Name — everything else is optional. A variable product imports as a parent row plus variation rows, linked by Parent, SKU and attributes. When converting an existing simple product into a variable one, the documentation notes that from WooCommerce 11.1 a single import is enough as long as the parent row sits before its variations in the file; on an older version, or when you can't guarantee row order, you need two passes — the parent product with attributes first, then the variations alone.

PrestaShop. PrestaShop's import tool expects a CSV file with a recommended semicolon separator — "We recommend using a semicolon ';' as a field separator" — in UTF-8 encoding (with ISO-8859-1 as an alternative) and dates in ISO 8601 format (docs.prestashop-project.org, read 2026-10-01). The documentation gives a sample header row and data for products: "Enabled";"Name";"Categories";"Price";"Tax rule ID";"Buying price";"On sale";"Reference";"Weight";"Quantity";"Short desc.";"Long desc";"Images URL" — the Reference column is the SKU, and Images URL only accepts URLs, not binary files, the same as Shopify and WooCommerce. One important constraint: data is imported for one language at a time — a multilingual catalogue needs as many import passes as there are languages. If you're specifically looking at integrating PrestaShop with wholesalers, this same CSV mechanism is the starting point — the import documentation doesn't describe a separate, built-in path for wholesalers, and the differences between wholesalers come down to the input file's format (separator, encoding, column names). If stock and price need to update more often than you can manually re-upload a file, you need the layer described below — an API or an integration tool.

XML product feeds — when CSV isn't enough

XML comes into the picture once the data exchange needs structure that CSV doesn't handle well — nested categories, variants linked to a parent product, or several images per product inside a single file. Unlike CSV, which every shop platform accepts as a flat table, a wholesaler's XML product feed is typically built to that wholesaler's own schema. There's no single industry-wide XML standard for B2B wholesale feeds the way there is for marketplace product feeds (see Google Merchant Center below) — each wholesaler, or the software platform behind it, tends to define its own structure, field names and even its own versioning.

Before building a mapping against a specific wholesaler's XML feed, confirm which exact schema and version it exports. Field names, nesting and even the file's root structure can differ not just between wholesalers but between versions of the same wholesaler's own export tool over time. A mapping that worked for one wholesaler's feed can fail silently against a different one's — the importer usually doesn't throw an error, it just picks up fewer fields than you expect, which is why the sync-log advice further down in this article matters as much for XML as it does for CSV.

If a specific wholesaler's own documentation recommends a particular XML structure, treat that as the source of truth over any generic "XML import" instructions in your shop platform's own documentation — platform import tools are usually built against a generic structure, and a wholesaler-specific feed adapts to it, not the other way round.

APIs and integrators — when you need real-time sync

If a change in the wholesaler's stock needs to reach your store within minutes rather than hours, a file (CSV or XML) uploaded on a recurring schedule stops being enough — that's when an API, or an integration layer that does the syncing for you, comes into play.

In practice, real-time wholesaler sync gets built one of three ways: through your shop platform's native connector or app for that specific wholesaler, where one exists; through a direct API integration with the wholesaler's own system; or through a general-purpose automation tool such as Zapier, Make or n8n, which checks for stock changes on a schedule (or receives them as they happen) and pushes the result into the store. The three differ mainly in pricing model and sync frequency. Zapier sells a plan with a monthly task allowance, Make bills in credits ("most actions consume 1 credit"), and n8n prices its cloud plans by monthly workflow executions, with a self-hosted Community Edition available on GitHub (n8n.io/pricing, read 2026-10-01). With a native connector, the sync frequency is whatever its developer built in — check it before you rely on it.

Whichever route you take, the lesson from file-based imports carries over: how often the integration checks for changes usually depends on the plan you pay for. Zapier's pricing page lists an update time of 15 minutes on the Free plan and 2 minutes on Professional; Make sets a minimum interval of 15 minutes between scheduled scenarios on its Free plan and 1 minute from Core upward (zapier.com/pricing, make.com/en/pricing, read 2026-10-01). Genuinely real-time sync — where the wholesaler's system pushes a change the moment it happens, instead of your integration checking on a timer — also has to be supported on the wholesaler's side, so ask for it before you plan around it. We cover the same trade-off from the marketplace side — syncing with a marketplace rather than a wholesaler — in our article on marketplace integration; the lesson is the same either way: choosing an integration layer is really a choice of sync frequency, not just a list of supported connections.

Dropshipping — the same mechanism, higher currency requirements

Dropshipping changes who physically ships the goods, but it doesn't change the integration logic — it only raises the bar on how current the data has to be. An order placed in your store flows automatically to the wholesaler (through an API or an order-exchange file), the wholesaler packs and ships directly to the customer, and you never hold physical stock. The consequence: if the wholesaler's stock only syncs once a day instead of in real time, the risk of selling something the wholesaler no longer has is higher than in a model where you hold your own warehouse — because you don't have a second layer of control (your own physical stock count) sitting between the customer's order and fulfilment. Running an integration off a dropship feed that's a day stale is, in effect, selling against stock you can no longer verify.

Dropshipping also has a consequence on the documents side, not just stock. It's usually you, as the seller the customer sees, who issues the invoice or receipt, even though the goods never passed through your warehouse — the wholesaler issues its own sales document to you, as a B2B recipient. These two documents (your invoice to the customer, the wholesaler's invoice to you) live in two different systems and don't need to match on number or date — if the flow between them isn't agreed in advance, it's easy for the bookkeeping to drift apart. Who should own which document when integrating with an ERP is a question we cover in more depth in our article on ERP, WMS and CRM integration.

A product feed to Google — a separate thing from the wholesaler import

Importing from a wholesaler feeds your product catalogue; a feed to Google Merchant Center is a separate file, built from your already-imported catalogue, not from the wholesaler's raw file. Google accepts three formats — "Delimited text files: .txt (tab-delimited text) or .tsv... XML files: .xml" — with a single-file size limit of 4 GB (support.google.com/merchants/answer/12631822, read 2026-10-01); neither of the two pages checked states a limit on the number of products in a file. You can upload the file by hand (in which case you have to re-upload it after every change), but Merchant Center also has a documented way to fetch the file from a fixed URL on a schedule — every 24 hours by default, with the schedule configurable (support.google.com/merchants/answer/12158380, read 2026-10-01). It's the same mechanism as a feed-by-URL for an XML product feed: you point to the address once, and the system polls it on its own, with no manual re-upload at every change. The full content requirements for the feed itself — title and description limits, GTIN, image requirements — are a topic of their own; this article only covers where the data for that feed comes from in the first place.

Common mistakes when integrating with a wholesaler

• Duplicate SKUs — the wholesaler uses the same identifier for a base product and its variant, and the field mapping in the store doesn't separate them, so the variants overwrite each other on every sync.
• Encoding mismatch — a file in ISO-8859-1 imported as UTF-8 (or the other way round) turns accented characters in names and descriptions into unreadable strings.
• VAT-inclusive and VAT-exclusive price swapped during mapping — the wholesaler sends a net price, the store interprets it as gross (or the other way round), which quietly wrecks margin across the whole catalogue with no visible import error.
• A race between the stock sync and the customer's order — if stock only updates hourly instead of in real time, you can sell something the wholesaler no longer has within that hour — the risk is higher with high turnover and with dropshipping.
• Images hosted at a non-public or temporary URL — a CSV import with image addresses on the wholesaler's own server, which later expires or blocks outside access, produces products with no images in the store, even though the import itself "succeeded."
• One file version for several languages — in a multilingual catalogue, if the importer (like PrestaShop's) only handles one language per run, trying to upload a single file with columns for several languages at once either fails outright or imports only one language, depending on the tool.
• No separation between the catalogue import schedule and the stock sync schedule — the mechanism described above: if both processes run on the same, infrequent cycle, stock and price are only as current as the rarely-updated catalogue, even though they could technically be refreshed far more often.

Most of these mistakes never produce an "import failed" message — the file loads without a problem, and the error only shows up in its effect: a wrong price, a missing image, or a product sold that no longer exists. That's why it's worth keeping a simple log for every sync (number of items updated, number of errors, how long it took) and comparing it against the previous run — a sudden drop in the number of updated items, even with no error message at all, usually means something changed on the wholesaler's side (file format, URL, column structure) before you'd otherwise notice it in the store itself.

If you're not sure whether building a full, automated integration with a wholesaler (API, real-time sync) makes sense at your catalogue's scale, or whether a recurring CSV import is enough, check our online store cost calculator — it accounts for catalogue size (SKU count) and integrations, including with an ERP system, so you can see how those two variables move the budget.

For the wider picture of where wholesaler integration fits into the rest of store operations — alongside ERP, WMS and automation — see our e-commerce operations hub.