Module psimport EN
Module psimport
Overview
psimport is a module for Dolibarr ERP/CRM published by Atoo-Net.
It bundles command-line tools to migrate a PrestaShop shop into Dolibarr: categories, third parties/addresses, products (with resolved VAT and cover image), downloadable files of virtual products, image galleries and orders. The migration relies on PrestaShop's REST Webservice API, with intermediate staging tables (llx_psimport_*) that let you inspect and fix data before the final import into Dolibarr, and replay an import without hitting the API again.
All products are imported as a service (Product::TYPE_SERVICE), since they are dematerialized modules, regardless of the type set on the PrestaShop side.
| Property | Value |
|---|---|
| Author | Philippe Grand — Atoo-Net |
| Version | 1.0 |
| License | GNU GPL v3+ |
| Dolibarr minimum | v24.0 |
| PHP minimum | v8.1 |
| PrestaShop supported | v1.6 to 9.x (Webservice API) |
Why use psimport?
psimport lets you bring all the data of an existing PrestaShop shop into Dolibarr, without a direct connection to PrestaShop's MySQL database (except for one optional, one-off step for downloadable files). Every step goes through a staging table you can review before the final import.
Use cases
Full migration of a PrestaShop shop
Retrieve categories, third parties/addresses, products (with VAT resolved via PrestaShop's tax rule groups) and orders, via the REST Webservice API, with no extra install on the PrestaShop side beyond enabling the Webservice.
Review before the final import
Each resource is first fetched into a staging table (llx_psimport_*) where the data can be inspected and corrected before the actual import into Dolibarr. This avoids hitting the PrestaShop API again in case of error.
Targeted replay after fixing errors
Every staging row carries a status (import_status). Rows in error can be reset to "to import" (the "Reset errors" button, or an SQL query) and replayed, without re-importing everything from scratch.
Retrieving downloadable module files
PrestaShop's Webservice API does not expose the files attached to "Virtual/downloadable products" (a limitation confirmed by the official PrestaShop/PrestaShop#27834 GitHub ticket). A "bridge" PrestaShop module shipped with psimport works around this, read-only.
Full product image gallery
Beyond the cover image (fetched together with the product), psimport can also retrieve each product's full image gallery via the products/{id}/images API sub-endpoint.
Installation
Requirements on the PrestaShop side:
- Enable the Webservice: Advanced Parameters > Webservice > Enable PrestaShop's webservice → Yes
- Create an API key ("Add a new webservice key") with GET permissions on:
categories,customers,addresses,countries,products,images,tax_rule_groups,tax_rules,taxes,orders,order_details - Note down the site URL and the generated API key
Requirements on the Dolibarr side:
- Enabled modules: Third parties, Products, Services, Categories, Orders, Invoices
- Enable the psimport module in Home → Setup → Modules/Applications ("Others" family)
Enabling the module automatically creates the staging tables llx_psimport_* through Dolibarr's standard module activation mechanism — no manual SQL import is needed.
The psimport module has no menu and no permission. Its only screen is the configuration page (Setup > Modules/Applications > psimport > wrench icon), where you enter the PrestaShop shop URL and the Webservice API key (constants PSIMPORT_API_URL and PSIMPORT_API_KEY), used by default by the CLI scripts when no parameter is passed on the command line. The whole migration is then driven from the command line via the scripts in the scripts/ folder.
Configuration
PrestaShop API connection
| Constant | Description |
|---|---|
PSIMPORT_API_URL |
Base URL of the PrestaShop Webservice API (e.g. https://www.yourshop.com/api)
|
PSIMPORT_API_KEY |
PrestaShop Webservice API key |
Troubleshooting: HTTP 403 on the API (hosting behind Cloudflare)
If the connection test (or any fetch-*/import-* script) fails with an error like HTTP 403 Forbidden with an empty response body and no redirection detected, while the same call succeeds in a browser, the block is probably not coming from PrestaShop but from an upstream application firewall (Cloudflare, ModSecurity, etc.) rejecting the request before it ever reaches the site.
Case encountered and confirmed on a Cloudflare (Free plan) hosting: Cloudflare's free Bot Fight Mode detects the module's cURL calls (no browser, no JS, non-standard User-Agent) as bot traffic and responds with a "Managed Challenge" — which shows up on the module side as an empty-body 403.
To confirm: in the Cloudflare dashboard, Security > Analytics > Events, filter on the last few minutes after a fresh test. If the blocked entry shows Service = "Bot fight mode" and Action = "Managed Challenge", this is the case.
On the Free plan, this Bot Fight Mode cannot be selectively bypassed per URL path. The only option is to disable the toggle globally: Security > Settings > "Bot fight mode" → Off while running the import scripts, then re-enable it afterwards if needed.
On a paid Cloudflare plan (Pro and above), Super Bot Fight Mode allows a finer bypass via a "Skip" Security Rule targeted at /api*.
Usage
Execution order
# 1. Categories php scripts/fetch-categories.php https://www.yourshop.com/api ABCDEF... 0 0 php scripts/import-categories.php 0 # 2. Customers + addresses php scripts/fetch-customers.php https://www.yourshop.com/api ABCDEF... 0 0 php scripts/import-customers.php 0 # 3. Products (VAT resolved via tax_rules_groups, cover image downloaded) php scripts/fetch-products.php https://www.yourshop.com/api ABCDEF... 0 0 php scripts/import-products.php https://www.yourshop.com/api ABCDEF... 0 # 4. Downloadable module files (requires the "Psimport Bridge" PrestaShop module) php scripts/fetch-product-files.php https://www.yourshop.com/api ABCDEF... 0 0 php scripts/import-product-files.php https://www.yourshop.com/api ABCDEF... 0 # 4b. Full product image gallery php scripts/fetch-product-images.php https://www.yourshop.com/api ABCDEF... 0 0 php scripts/import-product-images.php https://www.yourshop.com/api ABCDEF... 0 # 5. Orders (configure $importable_state_ids and $payment_module_map at the top of the script before the first run) php scripts/fetch-orders.php https://www.yourshop.com/api ABCDEF... 0 0 php scripts/import-orders.php 0
Common parameters:
limit= 0 to fetch/import everything, or a number to test on a sampleclean_all_before_fetch= 1 to empty the staging table before a new fetch (default 0 = accumulate/update)
Replaying an import after fixing errors
Each staging table has an import_status column:
0= to import1= successfully imported (fk_dolibarrholds the id of the created Dolibarr object)2= in error (details inimport_error)
To replay only the rows in error after fixing them, use the "Reset errors" button in the Import management tab, or:
UPDATE llx_psimport_product SET import_status = 0 WHERE import_status = 2;
then rerun the matching import script.
Downloadable module files
PrestaShop's Webservice API does not expose "Virtual/downloadable product" files (confirmed by official GitHub ticket PrestaShop/PrestaShop#27834 and several PrestaShop forum threads). This is worked around by a "bridge" PrestaShop module installed once on the shop.
Recommended: Psimport Bridge module (one-click, like every other import):
- Install the module shipped in
bridge/psimportbridge/on your PrestaShop shop (upload the zip from the back office, or copy it via FTP/SFTP intomodules/then install it) - No extra configuration needed: it reuses the same Webservice API key already set (
PSIMPORT_API_KEY) - In the Import management tab, use the ↓ Fetch and → Import buttons on the "Product files" row, exactly like every other resource
- Once the migration is done, the module can be safely uninstalled (read-only, no database or disk writes on PrestaShop)
This module only allows downloading files already referenced in ps_product_download (protects against arbitrary file reads).
Alternative (if the bridge module cannot be installed): a manual CSV export of ps_product_download from phpMyAdmin/Adminer, plus a local copy of PrestaShop's download/ folder, then php scripts/import-product-files.php /path/to/export.csv /path/to/download/.
Full product image gallery
fetch-product-images.php / import-product-images.php retrieve all images of each PrestaShop product (not just the cover), via the products/{id}/images Webservice sub-endpoint, into a dedicated staging table llx_psimport_productimage.
Points to check on the first run:
- Each image's position in the Dolibarr gallery is derived from the order returned by the API — visually check the order after import and manually reorder if needed
- To avoid showing the same picture twice (cover + gallery), exact duplicates are detected and silently skipped
- The exact shape of the JSON response can vary depending on the PrestaShop version: test first with
limit=5on a sample
Checks after each step
- Inspect the content of the
llx_psimport_*tables (data consistency, correctly resolved VAT) - In the Dolibarr UI, check: category tree, third-party records (address, contact), product sheets (price excl./incl. tax, VAT, image, attached file), orders (lines, totals, status)
- Compare counts (number of categories/customers/products/orders) between PrestaShop, the staging table, and Dolibarr
FAQ
Do I need direct access to the PrestaShop MySQL database?
No. The whole migration goes through PrestaShop's REST Webservice API, except for one optional, one-off step (manual CSV export) if the bridge module cannot be installed for downloadable files.
Which PrestaShop versions are compatible?
From PrestaShop 1.6 to 9.x, via the standard Webservice API. The bridge module (on the PrestaShop side) declares this compatibility range itself.
What should I do if a resource partially fails to import?
Fix the underlying data (in the staging table or on the PrestaShop side), reset the rows in error to import_status = 0 (the "Reset errors" button or an SQL query), then rerun only the matching import script.
The connection test fails with a 403 even though the URL works in a browser
See the HTTP 403 troubleshooting section: this is usually an application firewall (Cloudflare Bot Fight Mode) blocking cURL calls, not PrestaShop itself.
Does the Psimport Bridge module modify data on PrestaShop?
No, it is read-only: no database or disk writes on PrestaShop, and it only allows downloading files already referenced in ps_product_download.