PrestaShop and BaseLinker (base.com) integration

The same item sits in the store and on Allegro, and stock comes down in two separate tables. The order that arrives second ends in an apology and a refund, because the warehouse has nothing left.

Someone opens the store panel in the morning, then the marketplace panel, and retypes addresses into the shipping software. A typo in the house number then costs a parcel, not a moment of attention.

The parcel is packed and dispatched, but the order in the store still shows the status from the day it was placed. Customer service then answers questions the store should be answering.

A BaseLinker integration is deciding which side holds the truth for each field, then automatically exchanging data between the store and BaseLinker, the tool most Polish stores use to manage orders across the store and marketplaces such as Allegro. The catalogue, descriptions and prices usually run from the store, stock levels and order statuses from BaseLinker, and the rest of the work is making sure neither direction overwrites the other.

BaseLinker integration: what we actually do

• ✓ Syncing products, stock levels and prices
• ✓ Syncing orders from the store and from marketplaces
• ✓ Configuring statuses and order automation on base.'s side
• ✓ Mapping categories, attributes and variants
• ✓ Testing the full order cycle before the switch

The first decision comes before the integration: which system owns the stock level. Selling on several channels, that's base., because it collects orders from every channel. We set that once, document the mappings, and only then switch on the full catalogue.

• You sell in the store and on a marketplace from the same stock.
• Products have variants, and stock comes from several warehouses.
• Invoices and sales documents need to be generated from one place.

• It's about labels and parcel tracking: that's courier integrations.
• The store needs to talk to an ERP, not to base.: that's a dedicated solution.
• The store doesn't exist yet: the integration is part of the build.

The most expensive mistakes in this integration don't come from something failing to connect. They come from it connecting in both directions at once. A price corrected by hand in the store panel comes back overwritten from base., the stock level jumps between two values, and nobody can say which system holds the truth. That's why the first decision in an implementation isn't about scope, it's about direction.

By default we recommend one setup: the catalogue, descriptions and prices run in the store, and stock and orders from every channel are collected in base. The store is then the only place where you change a price, and base. the only place that takes stock down, whether the store or Allegro sold it. The reverse setup also works and can be the right one when the warehouse lives in an ERP system, but it has to be chosen deliberately, not discovered a month in.

The second decision covers what happens on a mismatch. A product that exists in base. but not in the store. An order for a variant pulled from sale. A promotional price arriving from both sides in the same minute. These situations happen in every store, so the rule for handling them is part of the implementation, not a subject for later.

The decisions that most often break this integration

Connecting the systems is the easy part. What's hard is what has to be settled beforehand, because it looks obvious until someone actually asks.

Four assumptions clients bring to BaseLinker

None of them is unreasonable, they all sound sensible, and every one has already cost someone a week of untangling data. Better to clear them up before implementation.

„Everything will sync both ways on its own”

The direction from the store to base. works well: products, prices, descriptions and photos flow through without trouble. The reverse direction is limited, and some data only comes back through a file export. That's why, during implementation, we name one system as the source of truth for the catalogue, instead of relying on both sides agreeing.

„We'll route Allegro orders through the store”

It can be done, but we advise against it. Marketplace orders should flow straight into base., leaving the store to handle the catalogue and prices. Routing them through the store creates a second handling path for the same order, and that's the most common cause of double shipping or stock mismatches.

„base. will replace our warehouse system”

base. is very good at collecting orders from many channels and handling them. Warehouse management is its weakest side, so with a high-bay warehouse or production you need a separate system for that, and base. stays the sales layer.

„Once implemented, it'll run without upkeep”

base. updates on its own side, and some updates need a fix on the integration. That's a normal maintenance cost, not a flaw in the implementation. Plan for it from the start, the same way you plan for updates to the store itself.

When an ERP joins the store and BaseLinker

In a larger company, base. is rarely the last link: accounting or the warehouse sit further down the chain. Below are four setups we come across, and what has to be settled in each one.

What we build around base. when the ready-made integration isn't enough

Connecting a store to base. is the starting point. Below are things we implement on stores where the standard connection stalls halfway.

PrestaShop stores: what our clients say

What we hear most often before the first sync

We check every one of them on a copy of the store before the full catalogue goes live.

„The base. module is already in the store, it just works”

The basic connection does, yes. Problems start with product variants, stock from several warehouses, and order statuses that are named differently in the store and in base. Integration is mapping those differences, not switching on a module.

„We sell on several channels, the stock will drift”

That's exactly why base. governs the stock level, and the store only reads it. We set the direction once and make sure an Allegro order takes stock down in the store too, before anyone buys the last unit twice.

„Implementation will stop our sales”

We run the integration on a copy and on a handful of test products, while the store keeps selling the whole time. We switch the full catalogue over only after verifying stock levels, and outside peak hours.

„We don't want an outsider to have access to our orders”

We get access on your own base. account, with permissions you grant and revoke yourself. After implementation, mapping documentation stays with you, so your team or the next contractor knows what flows where.

PrestaShop and BaseLinker integration: questions before you decide