INTEGRATION · PRESTASHOP
PrestaShop, and the adapter you’d copy
PrestaShop was the first shop we connected and it is still our broadest adapter — six capabilities, four side services, and integration tests that run against a real PrestaShop in a container. If you’re writing an adapter of your own, this is the package you start from.
WHAT’S LIVE TODAY
Source and destination, both directions
- → Catalog and inventory. Products and variants in PrestaShop are the source of truth for marketplace offers. Stock moves both ways — sell on Allegro, shop stock drops; sell in the shop, the offer follows.
- → Full order flow. Orders come out of the shop; status and shipments go back in. One fulfilment queue rather than a tab per channel.
- → Resumable ingestion. The adapter tracks a date_upd watermark. If a sync pauses, it resumes from where it stopped instead of replaying from zero.
- → Publish, don’t just read. OpenLinker also writes into PrestaShop — creating products and provisioning missing categories — when the shop is a destination rather than a source.
- → A companion PHP module. The OL Dynamic Carrier module returns marketplace shipping costs into the PrestaShop cart — the one part of this integration that needs code inside the shop. When it has no cost row for a cart it logs an error and marks the carrier unavailable: silent zero-cost shipping would be worse than a loud refusal.
- → Paczkomat-aware checkout. The adapter reads the buyer’s InPost pickup-point selection out of the PrestaShop checkout, so the label is generated for the locker they actually chose.
- → Six capabilities, four side services. ProductMaster, InventoryMaster, OrderSource, OrderProcessorManager, ProductPublisher, CategoryProvisioner — plus a connection tester, a webhook provisioner, and two shape validators.
- → Multiple stores, one instance. One OpenLinker instance runs several PrestaShop stores alongside several Allegro accounts, each connection holding its own encrypted credentials. The README’s example: two PrestaShop stores plus three Allegro accounts.
HOW IT WORKS
The package you copy to write your own
PrestaShop is the reference adapter. Its README says so plainly, and tells plugin authors to start by copying this package’s layout, because it implements the broadest capability set and registers the full side-service set. Its plugin descriptor and NestJS module are the canonical examples in the plugin author guide. Running pnpm create-adapter scaffolds the structure; PrestaShop shows you what to put in it.
For an agency, that changes the shape of the work: you are not reverse-engineering a channel manager. You start from a package that already implements six capability ports and you keep the plumbing — order ingestion, identifier mapping, idempotency, retry classification.
The reference adapter, with links to every capability implementation: PrestaShop adapter README →
BUILD THE ADAPTERS
Real integration tests, and you get the harness
Integration tests for this adapter run against a real PrestaShop install in a container, alongside a real Postgres and a real Redis. Not mocks of PrestaShop’s WebService — PrestaShop. That is what the two shape validators are tested against: PrestaShop’s own response quirks, rather than a fixture of them.
The harness is published as @openlinker/test-kit, so your adapter’s tests run on the same infrastructure: real Postgres, real Redis, real containers. You build the adapters. The foundation — including the way it’s tested — is already there.
HONESTLY
What’s here, and what isn’t yet
OpenLinker is alpha, pre-1.0. PrestaShop carries the broadest capability set of any adapter, and its integration tests run against a real PrestaShop in a container, not a stub. For contrast: WooCommerce is E2E-tested against a real WooCommerce, and the Allegro adapter has no CI run against live Allegro at all. The cost sits in one place — marketplace shipping costs need a PHP module installed in the shop. Catalog, inventory and orders sync without it.
FAQ
Common questions
Is the PrestaShop integration production-ready?
OpenLinker is alpha, pre-1.0. The PrestaShop adapter covers catalog, inventory, the full order flow, product publishing and category provisioning, and its integration tests run against a real PrestaShop in a container. It covers the broadest capability set of any adapter in the project — but the project itself is still early. Treat it as real, not as mature.
Why is PrestaShop called the reference adapter?
Because its README tells you to copy it. It implements the broadest capability set — ProductMaster, InventoryMaster, OrderSource, OrderProcessorManager, ProductPublisher, CategoryProvisioner — and registers the full side-service set in one package. For OAuth and token refresh, the Allegro adapter is the companion example.
Do I have to install a PHP module?
Not for catalog, inventory, and order sync — a WebService key is enough. The OpenLinker module adds marketplace shipping costs to the PrestaShop cart, which the shop otherwise has no source for. When the module has no cost row for a cart it deliberately marks the carrier unavailable rather than quietly charging zero for shipping.
Can I run several PrestaShop stores?
Yes. One OpenLinker instance runs multiple PrestaShop stores and multiple Allegro accounts at once, each connection holding its own encrypted credentials. The README’s example: two PrestaShop stores plus three Allegro accounts, one instance.
Which marketplaces can I connect PrestaShop to today?
Allegro and ERLI are live. eBay, Amazon, OLX, Empik and others are planned, not done — check the integrations scorecard before assuming anything works. On shipping, InPost and DPD are live; on invoicing, Subiekt nexo, KSeF and inFakt.
Is there a per-order fee?
No. OpenLinker is self-hosted and open-source (Apache 2.0) — you pay for the server you’d run anyway. Marketplace commissions still apply; those are the marketplace’s fees, not the integration layer’s.
Try the version you own.
The repo is public, Apache 2.0. The dev stack comes up with a single Docker command.