How to automatically import wholesale products into an online store

Entering a few products by hand is manageable. When a supplier provides hundreds or thousands of items, copying names, images, variants, prices and stock levels quickly becomes a full-time job. A one-off catalogue upload does not solve the underlying problem either. Supplier data changes every day, and the online store needs to keep pace with availability and pricing.

An automated wholesale product import retrieves a catalogue from XML, CSV, Excel or an API, maps it to the store's structure and updates selected fields on a schedule. A reliable integration should not copy everything without checks. It needs to identify products correctly, preserve manual improvements, reject invalid records and report problems.

What does an automated wholesale product import involve?

The integration connects the supplier's data source to the ecommerce platform. On a schedule, it retrieves the catalogue, validates its contents, transforms the data and creates or updates products in the store.

A typical flow has six stages:

1. Retrieve the latest file or API data from the supplier.
2. Validate required fields, formats and identifiers.
3. Map categories, variants, units, prices and availability statuses.
4. Compare the source data with products already held by the store.
5. Create new items and update only the fields owned by the supplier.
6. Record a report and send an alert when some data cannot be processed.

The first import builds the catalogue. Later runs are primarily synchronisation jobs. The distinction matters because an update should not necessarily overwrite a product name, description, image or category assignment again.

XML, CSV or API: how can a supplier provide product data?

The first step is to establish which data source the supplier offers. Its format affects the stability of the connection, the available update frequency and the way errors are handled.

Source	When it works well	What to check
API	Prices and stock need frequent updates, and the supplier provides documentation	Rate limits, authentication, incomplete documentation and outages
XML or JSON	The supplier publishes a complete feed on a regular schedule	Large files, structural changes and missing fields
CSV or Excel	The catalogue is straightforward or runs only a few times per day	Character encoding, number formats, column order and manually altered files
FTP or SFTP	The supplier places a file on its server	File availability, secure credentials and recognising a new version
Scraping	No stable API or feed exists, and the intended data use is permitted	Website changes, greater fragility and rights to retrieve and republish content

When a properly documented API is available, it usually provides the most control. The integration can retrieve changes more frequently and may also be able to submit orders or query a specific SKU. An XML or CSV feed is simpler and can be entirely adequate when the supplier refreshes it reliably.

Scraping should be a last resort. A human-facing website changes more often than a dedicated integration interface, and technical access to data does not automatically grant the right to reuse it. Check the commercial agreement and relevant licences before publishing descriptions or images.

Which product data needs to be mapped?

Two catalogues rarely use an identical structure. A supplier may have its own column names, categories and statuses, while the store expects a different format. Mapping determines where each value goes and how it is transformed.

Identifiers: SKU, EAN and supplier ID

Every product needs a stable key that allows the integration to recognise it during the next run. This is commonly a supplier SKU, EAN or an immutable identifier returned by the API.

The product name is not a reliable key. If the supplier corrects its spelling or adds a capacity to the name, the system may treat the same product as a new one and create a duplicate. The source of each identifier should also be retained when the store uses multiple suppliers.

Categories and attributes

A supplier category such as “Home / Kitchen / Small appliances” may correspond to “Kitchen equipment” in the store. A mapping table is needed instead of simply copying the category name.

Attributes require similar work. “Graphite”, “dark grey” and a manufacturer colour code may represent the same option. Standardised attributes improve storefront filters, product variants and search quality.

Variants

Sizes, colours and capacities may arrive as separate products or as variants linked to a parent product. Before integration, decide how the store should display them and which identifier belongs to the product and which belongs to the specific variant.

A mistake here can produce multiple separate product pages instead of one page with a size selector. It can also update the inventory of the wrong variant.

Prices, tax and margin

A feed may contain net price, gross price, recommended retail price, currency or several price tiers. The integration must define:

• which source price is used for calculations,
• whether tax needs to be added,
• how the margin is calculated,
• how prices are rounded,
• what happens when a source price is empty or changes sharply,
• whether store promotions may be overwritten.

The pricing rule should be configurable. A margin change can then be made without rebuilding the entire integration.

Stock levels and availability

One supplier provides an exact quantity, another uses statuses such as “high”, “low” and “unavailable”, while a third returns only a yes-or-no availability value. These values need to be translated into the store's inventory rules.

A safety buffer is often sensible. If a supplier reports its final unit, the store may publish zero stock to reduce the risk of accepting an order after that unit has already been allocated elsewhere. With multiple suppliers, the integration also needs a rule for choosing a source and aggregating availability.

Descriptions and images

Descriptions and images may need to be downloaded from separate URLs. The system should verify file type and size, avoid duplicates, and handle unavailable links.

These fields do not always need recurring updates. If the store team writes original SEO copy or prepares its own photography, the integration can set supplier content only when creating the product and preserve the store's version during later synchronisations.

The first import and ongoing synchronisation are different jobs

The initial run often needs to create products, categories, attributes and media. It is heavier and more susceptible to data problems, so it should be completed in batches in a test environment.

Later synchronisations can retrieve only changes or compare the current source with the previous state. Fields that commonly require regular updates include:

• purchase and selling prices,
• inventory,
• availability status,
• dispatch time,
• whether the product is active in the range.

Names, descriptions, URLs, images and category assignments can remain under the store's control. Ownership should be defined field by field: supplier, store or manual staff decision.

How can prices and inventory be updated safely?

A stopped import is not necessarily the most dangerous scenario. A technically successful update based on invalid source data may be worse, such as setting every product to out of stock or publishing a net purchase price as the retail price.

Useful safeguards include:

• rejecting records without an identifier, price or another required field,
• stopping an update when the number of changes exceeds an agreed threshold,
• blocking prices below cost or outside an accepted range,
• previewing changes before the first import,
• processing the catalogue in batches,
• retrying only failed records,
• retaining the previous value and a history of import runs.

A dry-run mode is especially valuable. It produces a report showing how many products will be created, changed, disabled and rejected. Data is written to the store only after the rules and results have been reviewed.

What should happen to products missing from the latest feed?

A product missing from the latest file is not necessarily permanently discontinued. The source file may be incomplete, or retrieval may have ended prematurely.

A grace period is safer. The product can first receive zero stock, then become inactive, and only be hidden after a defined number of successful synchronisations without that record. Permanently deleting products automatically makes it harder to preserve URLs, order history and analytics.

How should the import be monitored after launch?

The integration runs in the background, but it should not be invisible. The person responsible for the store needs to know whether the latest synchronisation succeeded and how old the data is.

A useful report contains:

• import start and finish times,
• the source file version or timestamp,
• counts of new, updated, skipped and invalid products,
• error examples with their product identifiers,
• the time of the last successful price and inventory update.

Critical failures should trigger an email or a message in the team's communication tool. A temporary API failure can be retried automatically, but repeated failures need human attention. Invalid products can be moved to a quarantine queue so one record does not stop the full catalogue.

Importing from one supplier or several

With one supplier, the product source is clear. With several, the system also needs to identify matching products, select a supplier, compare purchase prices and calculate storefront availability.

EAN can help combine offers, but it is not always present or correct. Matching may require a manufacturer code, brand and variant. The system should retain a separate offer for every supplier and calculate the customer-facing result from those offers. Changing the preferred supplier then does not require the product itself to be rebuilt.

If several sources first need to be organised in one database, see our guide to combining data from multiple websites in one database or dashboard.

What do you need before integrating a supplier with your store?

Collect the following materials before development begins:

1. A sample XML or CSV file, or the API documentation.
2. Test credentials when the source requires authentication.
3. A list of fields that should be created and later updated.
4. Examples of simple products and products with variants.
5. Pricing, tax, margin and rounding rules.
6. Rules for missing inventory, price, image or category data.
7. Confirmation of which descriptions and images your agreement permits you to publish.
8. Access to a test copy of the store or a way to run a safe trial import.

You do not need to describe every exception immediately. A representative sample and a few troublesome products usually reveal where mapping is straightforward and where a business decision is required.

What does the implementation process look like?

The source and the store catalogue structure are reviewed first. The next steps define the data model, mapping rules and error-handling approach. A trial import runs on a limited number of products, and the result is compared with the source.

After approval, the integration can process the full catalogue and move into scheduled synchronisation. Frequency depends on the sales model and the supplier's capabilities. Inventory may need to be refreshed more often than descriptions or images.

Monitoring, alerts and documentation complete the implementation. They make it clear which data is controlled by the supplier, which belongs to the store and what to do when the wholesale feed changes format.

Is an off-the-shelf plugin enough?

Sometimes. If the supplier and ecommerce platform support a compatible, well-maintained format, an existing connector may handle a basic import.

A custom integration is more likely to be appropriate when:

• the feed requires cleaning or combining data,
• the store has its own category and variant structure,
• prices depend on several rules,
• products come from multiple suppliers,
• manual descriptions must not be overwritten,
• alerts, history and change approval are required,
• an existing connector does not handle failures safely.

The important question is not only whether a plugin can create a product. Ask what happens on the next run, when a source file is invalid or when the data structure changes.

Do you need to connect a supplier to your online store?

Send us a sample feed, API documentation and the name of your ecommerce platform. As part of our systems and data integration service, we can assess the catalogue, propose safe update rules and build an import around your workflow.

If you do not yet have a complete specification, use the contact form to tell us which supplier and store you use, the approximate product count and which fields change most frequently. That is enough to define a practical first stage.