Build vs buy for ecommerce integration: start from a foundation, not from scratch

This post is for companies that have already decided to leave their SaaS channel manager and run their own system. If you’re still weighing that, our post on one system you own covers the trade-offs. Here we assume the decision is made and look at the next one. Do you write the whole thing yourselves, or start from something that already exists?

We’re writing this as the people who spent the last two years building exactly that kind of foundation. The adapters for PrestaShop, Allegro or InPost were only part of the work. Much more of it went into things nobody sees in a demo.

Build vs buy: three routes

The first route is to buy a different tool. It’s the fastest, but it doesn’t fix what made you leave: the system is rented, you pay per order or a share of revenue, and anything unusual goes into the vendor’s queue.

The second is a custom ecommerce integration platform built from scratch, by your own team or an agency. You get full control, and you’re responsible for every line of code, including the parts that have nothing to do with your business.

The third is to build on an open-source foundation. The code and the data are yours, as with a custom build, but the technical layer already exists and already handles real orders. Your team writes what is specific to your company.

The difference between the second and third route comes down to what the technical layer costs. The easiest way to show that is with examples from our own code.

What the integration layer has to handle

Connecting a shop to a marketplace looks like a handful of API calls at first: fetch the orders, create them in the shop, send back the tracking number. The trouble starts in production.

No order can go missing

Workers restart, marketplaces return errors, the network drops for a minute. So every integration in OpenLinker remembers where it stopped: for Allegro that’s a position in the order-event journal, for PrestaShop the last change date and order ID. That sounds simple until you meet a shop that refuses to sort orders by change date. Those shops exist, so OpenLinker detects it and switches to reading by order ID alone.

The order that comes back

An Allegro order gets created in PrestaShop as a new shop order. The next time OpenLinker reads orders from the shop, it sees that order again. Without a dedicated guard, it overwrites the order’s source channel: the panel shows PrestaShop as the sales channel next to an Allegro buyer’s email, and the order drops out of shipping-status sync. We caught this on live data, and since then OpenLinker recognises orders it pushed itself.

”Finished” isn’t the same as “delivered”

One order can go to several places at once, for example two shops. If one of them rejects it, the background job still counts as done, so the failure has to show up on that order, for that destination. OpenLinker records job status and sync status separately, and the operator panel groups failures so they can be retried one by one or as a group.

Every system numbers things differently

The same product has one ID in the shop, another in the Allegro offer and a third in the ERP. OpenLinker keeps a single map of those links. An order with a product nobody has mapped yet gets the status “awaiting mapping” instead of failing quietly.

API access is a project of its own

Credentials for every integration are encrypted. Allegro’s OAuth tokens expire and have to be refreshed, and two processes must never do that at the same moment, so the refresh runs behind a lock. Then there are rate limits, separate for each integration and shared across every process, with priority for work a person is waiting on. Webhooks arrive out of order and sometimes more than once, so each one is checked for its signature and for duplicates.

Invoice or receipt

Whether an order gets an invoice or a receipt depends on the delivery country and on whether the buyer gave a tax ID. When the rules don’t settle it, OpenLinker holds the order and shows why, instead of guessing. It also reads back the invoice’s status from KSeF, Poland’s national e-invoicing system.

Tests against real systems

Some bugs only show up on a live instance. One example from our test stand: if the API key isn’t linked to a shop, PrestaShop 9 returns a 503 “webservice is disabled” even though the API is switched on. That’s why OpenLinker’s integration tests run a real PrestaShop 9, Postgres and Redis in containers.

We built this over two years, in more than 1,700 commits. Along the way we wrote down more than 70 architecture decisions, and every build passes more than 60 automated checks. Here is how the work splits when you build on OpenLinker:

What you write yourselves

Two things are left. The first is adapters for systems OpenLinker doesn’t cover yet: your ERP, your warehouse system, a marketplace without an official integration. In OpenLinker, an adapter implements one or more ports, such as orders, stock or invoicing. One command generates the skeleton:

pnpm create-adapter acme-erp

The plugin author guide covers the rest: credentials, OAuth, database migrations owned by the plugin, and tests. If your system needs its own screen, the admin panel takes plugins too.

The second is your business rules: how orders are routed, when they’re held, which documents they get. An adapter can also declare an entirely new capability, such as a pricing engine of your own. How it plugs into the core is something you agree with the maintainers, which today means us.

All of it is open source under Apache 2.0. You can read the code, change it and, if it ever came to that, carry it on without us. The data stays on infrastructure you choose. We explain why the licence matters for this decision in open source or just source-available.

Who builds it

You don’t have to build it alone. We’re happy to implement, extend and customise OpenLinker for your company, from a single adapter to the whole rollout. You can also work with an agency you already use or an OpenLinker partner (here’s how it looks from the agency side), or rely on your own developers. Once the system is business-critical, you can add an SLA, managed hosting and Integration Assurance (maintenance and a guarantee that integrations keep working when APIs change).

We showed what this can look like at a larger company with a fictional brand selling in nine countries through its own shops, Amazon, bol, Kaufland and EDI wholesale: multi-country ecommerce operations on a stack you own.

When it isn’t worth it

If you run one shop on one marketplace with a standard process, a ready-made tool will be simpler and cheaper to keep running. If your team doesn’t work in TypeScript and you don’t want a partner, a foundation built on TypeScript, NestJS, React, PostgreSQL and Redis will be someone else’s code to you. And if integrations are the product you sell, you’ll probably want your own core anyway.

OpenLinker is still before version 1.0, but it’s ready for production and already handles real orders. Live integrations include PrestaShop, WooCommerce, Allegro, ERLI, InPost, DPD, Subiekt, KSeF, inFakt and eparagony.pl. Multi-location stock and per-channel pricing rules have a first version, and in-store sales are on the roadmap. The current list is on the integrations page.

The code is on GitHub, and you can try the admin panel in the live demo. If you’d like to talk about a specific project, get in touch through OpenLinker for enterprise.