Skip to content
BestCoding
pl

Connect PrestaShop to your ERP, warehouse and company systems

We build integrations for companies an off-the-shelf module cannot serve. Orders, stock, prices and documents move on their own — no re-keying by hand, and none of the mistakes that come with it. The integration fits your process, not the other way round.

Check what can be integrated See the multi-location project
  1. ERP, warehouse, marketplaces
  2. Integration layer: queue and rules
  3. PrestaShop
  4. Couriers, accounting, in-house apps
  5. Monitoring and event log
Running in production
PrestaShop + Subiekt GT, several locations
No re-keying
orders and stock move on their own
Orders split
the system picks the fulfilling location
Every operation
traceable in the event log

What you actually need

The word “integration” covers several different problems, and each one is solved differently. Below are the situations we see most often, and the best place to start with each.

  • Type of problem

    The systems are not connected at all — data is retyped by hand

    Recommended solution

    Building the integration — what this page covers. We start with the process and data map, then implement.

  • Type of problem

    An integration exists, but it loses orders, statuses or payments

    Recommended solution

    Order flow audit — find the point of failure first, fix it second.

  • Type of problem

    It is unclear whether the architecture will hold up as the business grows

    Recommended solution

    eCommerce consulting — an independent architecture review and recommendations before you invest.

  • Type of problem

    The process needs judgment and interpretation, not just moving data

    Recommended solution

    AI and automation — for documents, unstructured text or ambiguous classification.

An example of our work

How we automated order fulfillment across several locations

Our client sells both online and in several physical locations. One process runs continuously in the background: Subiekt GT — a Polish sales and inventory management system — feeds prices and stock levels into PrestaShop. The second process covers fulfillment: deciding who should prepare a given order when the stock is spread across locations. We built a dedicated system connecting PrestaShop, Subiekt GT and desktop applications running at the points of sale.

  1. 1 A customer places an order in the PrestaShop store.
  2. 2 The system checks availability of the ordered products across the individual locations.
  3. 3 Fulfillment rules point to the location that should prepare the order. If no single location holds all of the items, the order is split across several locations.
  4. 4 In a dedicated app, staff see the products they need to pick and ship from their own location.
  5. 5 Each part of the order ships to the customer as a separate parcel, and the statuses flow back to the store.

Result: The integration runs in production and splits orders across the points of sale on its own, with no data re-keyed by hand.

Safeguards: queued operations, automatic retries of failed attempts, an event log for every synchronization, and alerts when the data exchange stops.

This was built around the client’s process, not an off-the-shelf module imposing a way of working. With different fulfillment rules, the system would look different too.

Have a similar process? Tell us about it

What an integration is built from

Systems we connect to PrestaShop

  • ERP, sales and inventory systems: Subiekt GT, Comarch ERP, enova365 and others
  • Marketplaces: Allegro, Amazon, eBay and industry-specific platforms
  • Accounting and invoicing software, WMS and PIM systems
  • CRM, customer service and helpdesk systems
  • Couriers, shipping brokers, parcel lockers and payment providers
  • Windows and mobile apps, wholesaler systems, devices on the local network, and your own API

Data that flows through it

  • Products, variants, images and descriptions
  • Prices, promotions and discount rules
  • Stock levels per location
  • Orders and everything needed to fulfill them
  • Payment, picking and shipping statuses, and tracking numbers
  • Invoices, receipts, credit notes and warehouse documents

An integration you can rely on

  • One system going down briefly does not lose orders — they wait in the queue and resume when it responds again
  • Failed operations retry automatically, with a growing interval
  • The same operation will not create a second order or document, even if the event repeats
  • You learn about a stalled data exchange from an alert, not from a customer
  • Every exchange can be traced — what was sent, when, and with what result
  • We pass customer data only to the extent a given operation requires
  • We test changes on a staging environment before they reach production
  1. Event in the source system
  2. Queue and data validation
  3. Write to the target system
  4. Confirmation and event log entry
  5. Retry on failure
  6. Alert if the problem persists
A model integration flow. The details depend on the systems being connected and on what they actually expose.

Problems this solves

Where these projects usually start

These are the situations we hear about most often in a first conversation. If you recognize even one, it is a good place to start.

  1. Stock in the store differs from stock in the ERP — you sell items you do not have

  2. Orders are re-keyed into the ERP by hand, late and with typos

  3. Prices and promotions are updated separately in two places

  4. The integration works until something jams — and nobody notices it stopped

  5. An order goes to a location that does not hold all of the items

  6. An off-the-shelf connector does not support how the company actually works

How the process works

  1. 1

    Process and data map

    We establish what should happen and which way the data flows, and check what the connected systems expose.

  2. 2

    Design and quote

    Rules, sync directions and the handling of edge cases — written down before the work starts.

  3. 3

    Build on staging

    We build and test the integration on real data, away from production.

  4. 4

    Production launch

    A controlled switch-on with a rollback path and close watch on the first operations.

  5. 5

    Monitoring and growth

    Alerts, log reviews and further improvements as the process in your company changes.

Related services

Frequently Asked Questions

Which systems can you integrate with PrestaShop?

We integrate PrestaShop with practically any system that allows a secure data exchange — through an API, webhooks, a database, files, or a dedicated integration layer. Most requests involve an ERP or inventory system (Subiekt GT, Comarch ERP, enova365), a marketplace, accounting software, WMS, CRM, couriers and payment providers, as well as in-house applications and your own API.

What if our system has no API and no documentation?

We start by checking what the system really exposes: a database, file-based exchange, an export, an import routine, or an interface that was never documented. An integration is very often possible without an official API. We check initial feasibility before quoting and say plainly when an integration does not make sense. If the investigation needs to go deeper into the system, we agree its scope and cost upfront.

How is this different from a ready-made connector from the module marketplace?

An off-the-shelf module supports the process its author had in mind and expects your company to fit that shape. If your process fits what the module offers, it is the sensible and cheaper choice — and we will say so. We build a dedicated integration when the process is specific: your own fulfillment rules, several systems at once, or steps a ready-made product does not anticipate.

What happens when one of the systems stops responding?

Sales carry on — operations wait in the queue and resume once the system responds again, so data from the outage usually does not have to be re-entered by hand. If the outage drags on, you get an alert, and the log shows which operations are waiting and since when. Manual work is left only where an operation cannot simply be replayed — and the log tells you which one.

Will an integration slow the store down?

It should not. The data exchange runs outside customer traffic — operations are handled asynchronously through a queue, not while a page is loading. For large catalogs we sync differences rather than everything, and schedule the heaviest operations for quieter hours. If the store is already slow, performance optimization is the better place to start.

How long does an integration take to build?

It depends on how many systems are involved and what they expose. A simple one-way stock sync is a different scope from a process spanning several systems and fulfillment rules. You get the timeline with the quote, and the quote follows the process and data map — we agree the scope and cost of that map upfront, because only the map shows exactly what has to be built. The build itself is split into stages, and the first one usually delivers a working, narrow slice of the integration.

Who maintains the integration after launch?

We can handle maintenance: monitoring, alerts, reacting to changes in the connected systems, and further improvements. We can also hand the integration and its documentation to your own team or another supplier. We agree the scope and form of that care before the production launch — it is not added automatically.

Find out whether your process can be integrated

Just tell us which systems you run. We will say whether an off-the-shelf solution is enough or a dedicated integration is needed, and where to start — in writing, with a live call when it helps.

Check what can be integrated Get in touch: contact@bestcoding.net