Import and synchronize PrestaShop products safely

What we would do

The route depends on your existing catalog and data quality, supplier feeds, installed modules, integrations and theme requirements, and which fields staff maintain by hand. For a one-off spreadsheet load, we would first test the native CSV importer on a staging copy using that shop’s sample format. For repeated supplier updates, assess a reviewed feed-sync module before commissioning an API script. For exports, start from the receiving system’s required fields. For a two-way ERP connection, define ownership, conflicts and recovery before choosing an interface.

If the workflow needs a distinct integration, our PrestaShop Custom Module Development Service starts with a written specification covering business rules, connections, exclusions and acceptance criteria, followed by a fixed quote; third-party fees and infrastructure changes are separate.

Choose CSV, an API or a recurring feed

Use Advanced Parameters > Import for a prepared CSV and a one-off or occasional load. Use an integration worker when you need recurring supplier or ERP synchronization, reliable retries or transformations that a spreadsheet cannot maintain. A PIM can own richer catalog data, but it still needs a tested mapping into PrestaShop.

The native CSV importer does not consume an arbitrary supplier XML feed. Convert that feed to the selected CSV entity format, use a connector that explicitly supports its structure, or write an integration against an available API. Nested variants, repeated image values and language fields need deliberate mapping; changing the file extension does not convert the data. A scheduled export/feed module can produce recurring marketplace files; a manual catalog-grid export is not a complete backup.

Choose between these approaches from a representative trial and your operational needs. Catalog size alone does not select the method. Image downloads, combinations, hooks, server limits and data quality affect capacity. Start with a representative sample containing accents, multiple categories, variants and images. Choose batch sizes from measured completion times.

When the import is part of moving to a new shop, the usual route is a clean target shop on staging, loaded by a rehearsed data migration, then a planned cutover. For migration-specific account, order and URL handling, see the platform migration guide.

Agree field ownership before importing

Write down which system owns each field: the supplier, your ERP or PIM, or staff in the back office. A run should change only the fields it owns. Staff-written descriptions, your own photographs and an approved selling price stay protected unless the agreed rule says otherwise.

The following is an illustrative mapping specification, not an importable CSV or a promise that a particular tool exposes these field names:

Write the create, update and missing-record rules beside it, separately for parent products, combinations and each shop. Agree whether a blank cell means leave unchanged, clear the value or reject the row. Resolve duplicate references, blank identifiers, unknown parents and missing categories before applying a batch.

For a two-way connection, also agree how a later shop sale interacts with an older ERP stock update. Ask the developer to demonstrate ordering, conflict resolution and recovery, rather than letting whichever write arrives last become the accidental rule.

Prepare the CSV and map fields

1. Keep an untouched copy of the source file and make every correction on a copy.
2. Download the example file for the entity selected in the actual Import screen. Available fields differ by entity and release.
3. Save as UTF-8. The native importer in PrestaShop 1.7.8 and 9.1 skips a UTF-8 byte-order mark automatically. Removing a BOM is not a required repair for that importer.
4. Set the field separator and multiple-value separator to match the file. The default field separator is a semicolon. Quote fields containing the delimiter, embedded quotes or line breaks, using CSV escaping.
5. Map columns explicitly, skip the header row and save a named mapping if you will reuse it. Verify the language, shop context and all destructive options before starting.
6. Run a small sample and inspect the actual products. Check tax, identity and stock mapping on the imported products as well as CSV syntax.

Active;Name;Reference;Price tax excluded;Tax rule ID;Quantity
1;Blue widget;WIDGET-BLUE;100.00;1;12

This is an illustrative header, not an automatic mapping contract. Map each column in your installation. When loading the source into spreadsheet software, set references, GTINs and postal codes to text before automatic conversion can remove leading zeros or alter long identifiers. Compare the saved file with the original to confirm that leading zeros and long references survived. Excel’s encoding depends on the selected export format and platform; inspect the resulting file, for example with an accented product name, rather than trusting the export label. Investigate the failed row before changing CRLF line endings.

Quoting matters as soon as a value contains the separator. This supplier-file fragment illustrates quoting only; it is not a native import template:

supplier_sku;description
MUG-BLUE;"Blue mug; gift range"

The semicolon inside the description must stay part of that value. Open the file with the intended parsing settings and confirm that each row has the expected number of columns before you map it.

Import categories before assigning products to them. Keep an explicit category mapping. Check whether your chosen field accepts an ID or name and whether an unknown name creates a category. Do not treat arbitrary entity columns as interchangeable identifiers.

Update existing products and import combinations

Decide whether a record updates an existing product or creates one. In PrestaShop 1.7.8 and 9.1, product-reference matching requires the reference-matching option. To match the product ID column, enable “Force all ID numbers”: otherwise the product importer discards that ID before matching. With this option enabled, an ID that does not exist can create a product with that ID. Check every target ID and reference before importing, and reject ambiguous references.

Import parent products first, followed by a separate Combinations pass. For the parent, provide the target Product ID, or enable reference matching and supply its Product Reference. A combination’s own SKU/reference is different from its parent reference.

1. Map variant axes such as Size and Color to attribute groups and values. Review attribute names and values for inconsistent spelling before creating combinations.
2. Map descriptive specifications that do not select a variant to features.
3. Set each combination’s reference, supplier reference, identifiers, stock and price/weight impacts as needed.
4. Use the Combinations import’s default flag for the intended default combination.
5. Check every imported variant’s selectable value, final price, image and quantity.

For example, if the parent’s tax-exclusive price is EUR 100 and a variant should sell for EUR 120 before tax, its price impact is EUR 20. Do not import the full EUR 120 as that impact. Test a second import to confirm it updates the intended records rather than duplicating them. Prove the matching rule with an existing product and an existing variant, then rerun the same sample and check protected descriptions, images and prices as well as duplicate counts.

Map taxes, prices and stock in the right scope

The native importer exposes separate Price tax excluded and Price tax included fields. Use the field matching your source. When importing gross prices, confirm the tax rate used to derive the stored base price. Assign the correct tax rules group and check destination-specific cart totals. Mapping EUR 120 gross as EUR 120 net does not become correct merely because you select a tax group.

Keep supplier purchase cost, selling price, currency conversion, discounts and tax treatment separate. Check effective selling prices after combinations, specific prices and catalog discounts, rather than relying only on the base-price column.

If the job is only a bulk price adjustment, Mass Price Updater offers percentage or fixed adjustments to retail or wholesale prices, a mandatory preview and recorded previous values for verified restoration, without an export and reimport. It is a different task from synchronizing a supplier catalog.

Stock belongs to stock_available. Use PrestaShop stock services, StockAvailable or the supported API resource rather than updating the legacy product quantity field directly. Correct stock operations also notify relevant hooks.

Scope prices to the intended product_shop record. Scope stock to the shop or shared-stock shop group. Combination quantities require their own product-attribute IDs; a product-level row is not an extra stock pool to add to all combination rows.

The out_of_stock setting selects deny, allow or inherit. Inherited behavior reads PS_ORDER_OUT_OF_STOCK in the applicable configuration context. A zero quantity can still be purchasable if ordering out of stock is allowed.

Handle images and large imports

The native importer processes offset/limit batches. It does not necessarily fetch every image in one long request. A slow or broken remote image can still exhaust one batch’s limits.

1. Import core product data first, with images omitted, and validate it.
2. If the chosen importer supports a separate image-update pass, rehearse it with the required fields and proven matching rule before applying it. Check remote access, certificates, redirects, image size and server disk space. Rehearse that pass without deletion and confirm that rerunning it does not append unwanted copies.
3. Use the importer’s option to skip thumbnail regeneration when appropriate, then generate the needed thumbnails after the load. Keep the image formats your theme requires.
4. Use “Delete existing images” only for a planned replacement: it can remove manually added images on matched products.
5. Measure whether downloads, resizing, database writes, hooks or indexing dominate. If you suspend automatic search indexing during a controlled load, rebuild the relevant search and faceted indexes afterwards.

Inspect upload_max_filesize, post_max_size, memory_limit, max_execution_time and max_input_time. For multipart uploads, also check the applicable upload-count limits. PHP-FPM termination limits, web-server/proxy read timeouts and CDN request limits are separate constraints. Increasing one PHP value does not override all of them.

A CLI or cron worker removes the browser request from the process but still has memory, execution and operational limits. Do not assume a native prestashop:import command exists. Check your installation’s available commands or use a maintained importer with an identified worker.

Rehearse a dry run and a selective rollback

Rehearse routine imports on an isolated staging copy of the live shop. For migration, rehearse on the clean target shop described above. A successful import does not establish that the changes are correct for your business: inspect product pages, combinations and cart totals.

1. Prepare recovery. Back up the database, files and images, verify that recovery is possible, and use staging. Isolate the copy from live payments, customer messages, suppliers and fulfillment systems.
2. Build a representative sample. Beyond accents, multiple categories, variants and images, include an existing item, a new item, missing identifiers, a suspect price and a failed image, plus the relevant language and shop cases.
3. Review proposed changes. Use a tool’s preview where available. Otherwise compare staging before and after; do not describe an unreviewed live import as a dry run. Count creations, updates, exclusions and failures.
4. Check the shop. Inspect actual product pages, combinations, availability, images and cart totals, alongside the import log. Prove that protected fields stay unchanged and that rerunning is safe.
5. Prove reversal. Rehearse the tool’s documented rollback or a scoped recovery. Account for later staff edits and orders so recovery does not overwrite newer business data.
6. Launch a measured batch. Choose its size from the measured staging completion time. Reconcile counts, failures and changed values before continuing, and pause the schedule if results differ from the agreed rules.

A full database restore on a trading shop can discard newer orders and payments. Agree how these would be preserved before any destructive operation; retained feed values are not a substitute for a recoverable shop backup either. Do not delete products, prune image formats or raise server limits as a first response to a failed import.

What the agency should hand over

• A field-ownership and identity mapping, including products, variants, shops and languages.
• The tested importer or API operations, source formats and permissions, with credentials excluded from ordinary run logs.
• Evidence for duplicate, blank, missing-record, suspect-price, rejected-row and interrupted-run cases, plus agreed stop conditions and what happens when two runs overlap.
• The schedule owner, failure alert route, restart procedure and rehearsed recovery steps protecting later orders and edits.

If stock ownership is the wider problem, see the inventory management guide. The integration should follow the agreed operating process.

Diagnose a failed or partially completed import

1. Save the failed file, mapping, options, time and last confirmed records. Pause scheduled or overlapping runs that could write to the same records. Take a backup before repair.
2. Inspect the application, PHP-FPM and web-server error logs. Use the actual paths configured for your installation; var/logs/ is a common application location.
3. If the same row fails, isolate it and inspect required values, separators, quotes, encoding, category references and image URLs.
4. If failure depends on duration or batch size, measure the failing request and compare all timeout and memory limits.
5. Inspect the database and storefront to identify committed records. A blank page or failed batch does not imply that no rows were saved.
6. Resume using stable references or mapped IDs. Reconcile ambiguous records before retrying. Do not enable catalog deletion to work around an incomplete import.
7. Repair incomplete images, active flags or associations and rebuild applicable indexes after the final batch.

Export the correct shop, language and stock

A useful SQL export must include shop and language scope. The following read-only example exports aggregate product quantities for shop 1 and language 1 when that shop has its own stock. Replace the table prefix and IDs for your installation.

SELECT p.id_product, pl.name, p.reference,
       ps.price AS price_tax_excluded, sa.quantity
FROM ps_product p
JOIN ps_product_shop ps
  ON ps.id_product = p.id_product AND ps.id_shop = 1
JOIN ps_product_lang pl
  ON pl.id_product = p.id_product
 AND pl.id_shop = 1 AND pl.id_lang = 1
LEFT JOIN ps_stock_available sa
  ON sa.id_product = p.id_product
 AND sa.id_product_attribute = 0
 AND sa.id_shop = 1 AND sa.id_shop_group = 0;

For shared stock, select the actual stock-sharing group row, typically id_shop = 0 and the relevant id_shop_group. Do not add a loose OR that joins both scopes. For variant-level stock, export combination records and their references separately. Check how aggregate quantities relate to those records.

The query returns the stored base price, which is not necessarily what a customer pays after tax, combination impacts and specific prices. If SQL Manager is used for such a read-only extraction, have a developer review the joins and the shop, language and combination scope.

Use a recurring feed export when the destination needs current prices and availability on a schedule. It needs a generator as well as a schedule, delivery checks and an owner for failures; see the product-feed guide for destination requirements. Order and invoice exports are separate datasets (see order and invoice exports). Neither a product list nor this query provides a restorable database backup.

Write the export contract before building the export

Do not assume that a product-list export contains combinations, images, translated content or the prices the destination needs. Decide whether each row represents a parent product or a sellable combination, and identify its shop and language. Specify which price the receiver needs, including currency, tax basis and any customer-group context. Include availability, image and destination requirements in a sample that the receiving system accepts, and compare each sample export with that written field list. For a scheduled feed, check the delivered file’s freshness and contents, not merely whether a task reports success.

Use XML requests and JSON responses correctly

The legacy Webservice and the PrestaShop 9 Admin API are different interfaces. The legacy Webservice in PrestaShop 1.7.8 and 9.1 accepts XML entity writes and can return JSON using output_format=JSON. You do not need the newer API merely to receive a JSON response.

GET /api/products?display=full&output_format=JSON
GET /api/products?schema=blank

Enable the legacy service under Advanced Parameters > Webservice and grant only the required resource permissions. Protect keys and use HTTPS. Keep keys out of files shared with suppliers. Inspect the target resource schema before building requests, and confirm the exact release, installed extensions, permissions and accepted write format for every resource you need. JSON output does not prove that JSON writes are accepted, and another API may not expose every resource you need.

The PrestaShop 1.7.8 and 9.1 request implementations iterate over multiple XML entities in a write request. This is not a promise of an atomic bulk transaction. Earlier entities can be saved before a later validation or association fails. Test multi-entity behavior for your exact release and resource.

Log a run ID, source key, target ID, operation and sanitized response. On a timeout or ambiguous error, retrieve the target state before repeating a create. Retry transient failures with bounded backoff. Fix authentication, permission, schema and validation failures before retrying. Do not assume every HTTP 500 is safe to repeat.

Use the supported product-image upload endpoint for binary images. Plan products, combinations, associations and stock as related operations with checkpoints, and test product, combination, stock and image operations separately on the installed shop. Measure throughput and respect hosting or WAF limits; a fixed delay between requests does not predict total run time.

Use reviewed supplier updates and schedule them safely

Smart Wholesaler Feed Sync starts with a source, a connection test and sample-column mapping. Its product description includes managed fields, supplier priorities, pricing rules and protection for manual or frozen values. A before-and-after review, action limits and suspicious-price quarantine guard updates; each feed has its own schedule, and applied runs retain previous values for rollback.

Confirm that your source format, authentication and required fields are supported before choosing it. Decide what happens when a file is late, empty or incomplete, when several suppliers match the same item and when a price is rejected. Its description says safe stock and content updates can continue while a suspicious supplier price stays unchanged. Retained previous values support a selective rollback of that tool’s changes; they are not a recoverable shop backup and do not settle conflicts with later staff edits by themselves.

A supplier price changes, but your description should not

You have rewritten the MUG-BLUE description and taken your own photographs. A supplier file contains a new cost, stock information and an older description. The agreed run owns supplier cost and its defined stock contribution; your edited content remains protected. A retail price changes only through the approved pricing rule.

Now the supplier sends a suspicious price. Review the rejected amount and reason while confirming that permitted updates followed the agreed policy. If the file is truncated, pause it for review rather than applying absence as a catalog-wide stock change. Keep the source file and the run record so staff can explain which values changed and why.

Cron Manager can schedule background tasks and show results and failures. It is a scheduling tool: it does not provide the import mapping or turn an unsupported feed into a connector. Confirm that the chosen importer exposes a compatible task, and do not add another scheduler where the feed tool already schedules the job.

Stop bad supplier data before publication

Write down the supplier’s identity contract. A supplier ID can be stable or recycled. A GTIN, MPN or merchant reference can be missing, duplicated or assigned at a different level. Match within the intended supplier, manufacturer, product/combination and shop scope. Reject ambiguous matches.

Validate required GTIN lengths and check digits independently. In the PrestaShop 1.7.8 product model and 9.1 combination model, ean13 uses isEan13(), which accepts up to 13 digits. The PrestaShop 9.1 product model instead uses isGtin(), whose pattern accepts up to 14 digits. Neither pattern alone verifies the required GTIN length set or check digit. MPN fields are not available in every legacy version, including stock 1.6.1.24.

1. Stage the downloaded file. Check transfer completion, expected checksum where supplied, source timestamp and parse results.
2. Record run start/end, supplier, row count, previous row count, checksum, status and rejection reason.
3. Reject implausible changes or a truncated file before applying removals. A missing row only means discontinued when the source contract defines it that way.
4. Apply price floors and quantity-change guards before publishing. Alert on rejected changes instead of silently substituting a guessed value.
5. Record before/after values and target IDs. Validate before forwarding changes to marketplaces.
6. Separate discontinued supplier stock from real local stock. Sell remaining stock only according to your intended availability policy.

Separate missing information from an instruction to clear it

A supplier omits a mug from today’s file. That could mean a discontinued item, an incomplete download or a file that contains only changes. Agree what each source condition means before a run treats it as a stock or visibility instruction.

These are operating rules to specify and test, not a claim that every importer supplies these controls.

Phantom inventory can lead to overselling; wrong matching can publish another product’s price. Marketplace consequences depend on the channel and the operation performed. Replenishing, revising and replacing an offer do not universally reset its history.

Investigate duplicate identifiers and below-cost prices

These queries identify candidates for investigation. They do not prove an error. Replace ps_ with your database prefix.

SELECT ean13, COUNT(*) AS records_found
FROM ps_product
WHERE ean13 <> ''
GROUP BY ean13
HAVING COUNT(*) > 1;

SELECT p.id_product, p.reference, ps.id_shop,
       ps.price, ps.wholesale_price
FROM ps_product p
JOIN ps_product_shop ps ON ps.id_product = p.id_product
WHERE ps.id_shop = 1 AND ps.active = 1
  AND ps.wholesale_price > 0
  AND ps.price < ps.wholesale_price;

Repeat identifier audits for combinations and other fields only where those fields exist. Inspect shop and supplier scope before declaring duplicates defective. A product below its recorded base cost may reflect stale costs, an intentional clearance or incorrect mapping. Check tax/currency comparability, combination impacts and effective discounts before deciding what to change.

Keep an attributable stock-write trail and a recoverable snapshot. If an incorrect feed reaches customers, pause further propagation, identify affected listings and orders, and evaluate the actual contractual and consumer obligations. There is no universal financial rule that says cancelling all orders or fulfilling all orders is always cheaper.