Why an agency should own the WooCommerce integration layer, not bolt on another plugin

WooCommerce is now a live shop integration in OpenLinker — a self-hosted, API-first WooCommerce marketplace integration that runs on your own infrastructure. If you do multichannel work for client merchants, that one sentence is the whole reason to read on — but not for the reason you might think. The interesting part isn’t that we connected another store. It’s how cheaply we connected it, and what that says about where an agency should put its integration code.

So this post isn’t the feature tour. (If you want the what-it-does, the WooCommerce integration page covers ingestion, inventory, the setup wizard, all of it.) This is the argument we’d actually make to an agency tech lead: when your client sells on WooCommerce plus a marketplace or two, the default move — “find a WooCommerce marketplace plugin” — is the one that quietly costs you the most over the life of the account.

The default path, and why it ages badly

A client comes to you on WooCommerce. They want to sell on a marketplace too, keep stock honest across both, and pull every order into one place. The path of least resistance is well-trodden: search the plugin directory, find a WooCommerce channel manager plugin or a per-marketplace connector, install it, configure it, bill the setup, move on.

It works on day one. It ages badly, and it ages badly in a specific, predictable way.

Everything lives inside WordPress. Your multichannel logic — the thing that’s actually load-bearing for the client’s revenue — is now a plugin’s settings page, coupled to one store, one WordPress install, and one plugin vendor’s roadmap. When the client adds a second store, you do it all again. When they want a pricing rule the plugin didn’t anticipate, you’re writing it around the plugin, not into it. When the plugin vendor changes their pricing, or gets acquired, or ships a breaking update against a marketplace API change, that’s your client’s revenue on someone else’s timeline. And even when it’s GPL and you can read the source, you’re not forking and maintaining a marketplace plugin per client — so in practice it’s a box you file tickets against, on the vendor’s schedule.

None of this is unique to WooCommerce. It’s the same trap as renting a SaaS channel manager, just wearing a plugin’s clothes — and the “open source” label most WordPress plugins carry doesn’t change it, because the logic is still trapped inside WordPress and coupled to one store. The wedge isn’t open source. The wedge is self-hosted and API-first: a layer you own, sitting outside the store.

Move the integration layer out of the store

Here’s the shift. Instead of putting the multichannel logic inside WooCommerce, you put it next to it.

OpenLinker is a separate self-hosted service. It talks to WooCommerce over the WooCommerce REST API — the same way a headless WooCommerce order sync setup would, because to the orchestration core a store is just a source of orders and a place to publish listings. WooCommerce isn’t the center of the system. It’s one integration.

That reframing changes the economics for an agency in three concrete ways:

• One instance, many stores and marketplaces. Per-connection encrypted credentials mean two WooCommerce stores plus a couple of Allegro accounts run from a single OpenLinker instance. That’s self-hosted WooCommerce multichannel without standing up a new plugin stack per store.
• No per-order meter. It’s Apache 2.0 and runs on infrastructure you (or your client) control. The client stops paying a tax that grows with their success; you bill the deployment and the maintenance instead.
• The integration code is yours. Self-hosted, readable, testable. When a marketplace changes its listing flow next quarter, that’s adapter work you can do — not a ticket you file and hope.

That last point is the one that compounds over a multi-year account.

This isn’t theoretical for us, either. Our own dev stack boots a PrestaShop store and a WooCommerce store side by side, against a single OpenLinker instance, with the integration tests driving both at once. The day WooCommerce’s tests went green against the same core PrestaShop already used was the day “multiple stores, one instance” stopped being a diagram and became something we run on every build.

The proof: WooCommerce is the second adapter, on the same ports

We talk a lot on this site about “build the adapters, skip the foundation.” It’s easy to say. WooCommerce going live is the first time we can point at something and say that’s what we meant.

Here’s why. PrestaShop was our first live shop. When you build the first of anything, you can’t actually tell whether your abstractions are real or whether you’ve just described one integration in fancier words. The capability ports — order ingestion, inventory sync, product publish — looked clean, but a single implementation proves nothing. The test of an abstraction is the second thing built against it.

WooCommerce was that second thing. It’s a completely different platform — a REST API with consumer-key auth where PrestaShop has its webservice, a different data model underneath — and it slotted in as an adapter against the same ports PrestaShop uses, without changing the core. Same cursor-based, resumable order ingestion. Same bidirectional inventory sync. Same product publish, including bulk, this time over the WooCommerce REST API. Same guided setup wizard pattern. The domain core didn’t move.

That’s the strongest evidence we have so far that the plugin model holds — that the line between “the foundation” and “your adapters” is real, not marketing. For an agency, the implication is direct: a new shop, or eventually a new marketplace, is adapter code written against a stable plugin SDK — scaffolded with pnpm create-adapter, tested against a real instance with the exported Testcontainers test-kit — not a fork of the platform you then have to maintain forever. The plumbing every channel-manager project rebuilds — ingestion, retry, identifier mapping, idempotency — you inherit. The client-specific edges are what you build and bill.

Here’s the argument as one number. The WooCommerce adapter is roughly 3,900 lines of code. It plugs into about 47,000 lines of shared core it never had to touch — order orchestration, retry, identifier mapping, the sync engine, the job runner. The adapter is the translation layer to one platform’s REST API; the foundation underneath is the part you’d otherwise rebuild, badly, on every client project. A few thousand lines of adapter against a core an order of magnitude larger is “build the adapters, skip the foundation” — not as a slogan, as a line count. (It’s also about a third the size of the PrestaShop adapter that proved the ports first — the abstraction got cheaper to build against, not more expensive.)

What’s actually live, and what isn’t

We keep this honest because the whole pitch falls apart the moment we oversell it.

Live for WooCommerce today:

• Order ingestion — cursor-based and resumable, so nothing’s lost if anything pauses.
• Bidirectional inventory sync between WooCommerce and your connected marketplaces.
• Product publish, including bulk, via the WooCommerce REST API.
• A guided setup wizard, with encrypted per-connection credentials.
• Multiple stores from one instance.
• End-to-end tests against a real WooCommerce in Docker.

That last one isn’t a footnote. WooCommerce inventory sync to a marketplace is exactly the kind of thing that breaks silently without real integration tests, so we run them against the actual platform, not mocks.

On the marketplace side: Allegro and ERLI are connected today, so the full WooCommerce-to-marketplace loop works for those two right now. What’s not live yet: eBay, Amazon and the rest are planned, not done — they’ll arrive as adapters against the same ports, but they aren’t here yet, and we won’t pretend they are. OpenLinker as a whole is alpha, pre-1.0. The integrations scorecard is public and honest about every line: what’s live, what’s in progress, what’s only planned.

Here’s the part to be straight about, because it’s the real question for an agency outside Poland: if your client needs eBay or Amazon today, that’s an adapter you’d be writing — against the same ports WooCommerce uses, with us in the loop. That’s the honest deal at this stage. You’d be an early agency building a marketplace adapter on an alpha SDK, not pulling a finished one off the shelf. If that’s too early for the account in front of you, it’s too early — we’d rather you know it now than in production. But if you’ve been looking for a foundation to build those adapters on instead of renting someone else’s, that’s exactly the position this is built for.

Where an open-source WooCommerce marketplace integration leaves an agency

An open-source WooCommerce marketplace integration you actually own isn’t a category most plugin directories will sell you, because the incentive everywhere else is to keep the integration layer inside someone else’s product — a plugin, a SaaS, a black box with a monthly bill. The case we’d make is the opposite: own that layer. Put it outside the store, on infrastructure you control, in code you can read and extend, against a foundation built so that the next integration is adapter work and not a rebuild.

WooCommerce going live as our second shop is the evidence that the foundation holds. If your clients live on WooCommerce and sell across channels, this is worth a serious look:

• Read the WooCommerce integration page — the concrete what-it-does, integration by integration.
• Star the repo on GitHub — the clearest signal that a self-hosted, API-first channel manager is worth building.
• Talk to us as an agency — we’re working closely with the first few agencies building client work on OpenLinker, and there’s room for more.

We’re building this in the open, on purpose. Come build the adapters with us.