For most Polish SMEs, Allegro (the dominant local marketplace, similar in role to Amazon in the DACH markets) is either the second or the first sales channel. The pain doesn't start with the first listing — it starts around the fiftieth order per day, when someone in the company begins spending half a full-time job re-typing orders into the ERP and trying to keep stock levels in sync.
We see it in almost every commerce project. A company starts with a few listings, sales grow, six months later they have 40 active offers and a salesperson who spends one day a week only clicking: copying the buyer's address from Allegro into Comarch Optima, issuing an invoice, generating a courier label, going back to Allegro to mark "shipped". And when someone on Allegro buys the last unit of a product that a walk-in customer just took from the shelf on Friday evening — you get an oversell, an apology email, and a negative review by morning.
This isn't a problem that fades away. It's a problem that scales with sales.
What breaks without integration
Three classics, in this order.
Stock levels drift between channels. The ERP knows what's on the shelf, Allegro shows a different number because it's updated manually once a day at 8:00. In-store sales go through during the day, Allegro keeps showing full availability. Concretely: at one of our clients — an 18-person consumer electronics dealer — with 30–40 Allegro orders a day, we counted an average of 3 oversell cases per month. Each one is a negative review or a week-long sales-account penalty.
Manual re-typing eats hours. An Allegro order has to be entered in the ERP as a sales document, the customer data added, an invoice issued, a courier label generated, and the tracking number pushed back into Allegro. Eight to twelve clicks per order. At 30 orders a day, that's around 8 hours a week for one person, done purely mechanically.
Promo prices drift. You launch a promotion in the physical store, someone forgets to update Allegro. Customers notice the difference, some file complaints. The reverse happens too — a weekend price cut on Allegro doesn't roll back at the register on Monday.
None of these is a disaster on its own. Together, over six months, they cost more than a proper integration.
When BaseLinker (or similar) — when your own API
The Polish middleware market for this is mature — BaseLinker, Sky-Shop, Selly, IdoSell. They all do roughly the same thing: pull orders from Allegro (and other marketplaces), show them in one panel, push the order into the ERP, and return the shipping status. For most SMEs, this is the right first investment, not a custom integration.
BaseLinker (or a competitor) is enough when:
- You sell standard products, no configurators.
- Your ERP is Comarch Optima, Subiekt GT/Nexo, enova365, WF-Mag — they have ready-made connectors.
- Volume up to ~500 orders a day from Allegro.
- No unusual discount logic, contract prices, or complicated VAT-margin accounting.
Consider a custom integration against the Allegro REST API when:
- You sell configurable products (custom furniture, electronics with options) — middleware can't handle the variants well.
- Your ERP has weak connector support (Microsoft Dynamics AX, heavily-modified Business Central, custom in-house apps).
- You need specific logic: different source warehouses for different offers, shipping priorities, tie-in to a production system.
- Volume above 500 orders a day — middleware licensing starts to match the cost of maintaining your own integration.
In practice, about 80% of the SMEs we walk into should start with BaseLinker. The rest grow into a custom integration for a concrete reason, not because it's "cooler".
What a good integration actually does
Without going into code, a good Allegro ↔ ERP integration has four flows, handled independently.
- Product catalog: ERP (or PIM) → Allegro. New products, base price updates, descriptions, images, variants. Usually a nightly sync plus event-based pushes when a price changes.
- Stock levels: ERP → Allegro. Real-time or near real-time. Every stock movement in the ERP (in-store sale, warehouse release) hits Allegro immediately. This is the most critical stream — oversells depend on it.
- Orders: Allegro → ERP. A new Allegro order creates a sales document in the ERP (usually a release note or invoice), reserves stock, generates a courier label. No clicking.
- Shipping status: ERP → Allegro. When someone generates the label, the tracking number goes back to Allegro automatically and the customer gets the "shipped" email.
Each of the four flows should work even when the others fail. You do not want an integration that goes fully down on a single error.
Traps we keep running into
Race conditions on stock. The ERP pushes "5 units", at the same moment Allegro sells a sixth. Fix: reserve stock in the ERP at "new order" status, not only at invoicing. Skip this and Black Friday will kill you.
Rolling back promo prices. You launch a promo at 199 instead of 249. The integration pushes the new price to Allegro. The promo ends on Monday — who makes sure the price goes back to 249? Design this from day one, otherwise promo prices start "sticking" to Allegro for weeks.
Special characters in descriptions. Comarch Optima keeps the product description in a text field with hard line breaks. Allegro wants HTML with a specific allow-list of tags. Without transformation you get descriptions like " <br/>washing machine<br/>". Small detail — but the customer replies "this is gibberish".
Multiple warehouses on one Allegro account. The company has one Allegro seller account but three warehouses (Warsaw, Kraków, a dropship supplier). Who ships the order — Warsaw or Kraków? The rule has to live inside the integration (e.g. the closest warehouse by buyer's postcode), otherwise the sales team decides manually every day.
What it actually costs
Concrete case. Same 18-person electronics dealer. Before integration: one person full-time on Allegro — orders, shipping labels, statuses, stock updates, handling oversell complaints. After BaseLinker rollout with the Comarch Optima connector: 1 day a week for the same person, plus half an hour a day for exceptions (unusual orders, complaints).
Costs: BaseLinker in the right tier for their volume — about PLN 250/month. Setup and configuration (schema mapping, category mapping, testing with real orders) — one-off around PLN 6–10k, depending on the starting state. Time saved — about 24 hours a week freed up, plus zero oversells in the six months after go-live.
Payback: 2–3 months if you honestly measure only time saved. Much faster once you also count lost revenue from oversells and the cost of handling complaints.
Where to start
Don't start by picking a tool. Start with two questions on paper:
- How many Allegro orders a day do we handle, and who clicks them manually? Round it to hours per week — that's your "do nothing" cost.
- How many oversells or stock mismatches did we have in the last 3 months? If it's more than one — you have a problem, not just a cost.
If both answers are "more than zero" — the next step isn't "let's order an integration", it's "let's run a two-week pilot with BaseLinker on 10 selected offers". That verifies whether category and stock mapping work with your specific ERP setup, without risking the rest of the business. The full rollout decision comes after the pilot, not before.
This is one of those projects where most of the risk isn't the technology, it's fitting the process to the tool. Worth doing with someone who's already done a few of these — not to hand over all the work, but to skip the mistakes others made before you.
Manually re-typing marketplace orders isn't "our process". It's operational debt that grows with your sales.