INTEGRATION · ALLEGRO
The Allegro integration you host yourself
Allegro is Poland’s dominant marketplace and OpenLinker’s deepest adapter — the one the capability ports were shaped by. Full offer suite, OAuth, cursor-based order ingestion, GPSR. On your own server, with no per-order fee.
WHAT’S LIVE TODAY
The offer lifecycle, end to end
- → Complete offer suite. Create offers, update fields, read status, list offers, and consume the offer event journal. Single or bulk — and when a bulk batch partly fails, you re-run only the failed rows rather than the whole batch.
- → Category lookup by EAN. Give it a barcode; the adapter matches the Allegro category and pulls parameters from Allegro’s product catalogue. No hand-walking the category tree per offer.
- → GPSR and seller policies. EU product-safety data, responsible-producer ID, and seller policies are part of offer creation — first-class fields, not an afterthought.
- → Survived a breaking API change. Allegro withdrew multi-variant offers, and their API resources, in April 2026. The adapter now publishes one offer per variant and lets Allegro auto-group them by GTIN. The adapter changed; callers didn’t.
- → Bidirectional inventory sync. An Allegro sale draws down shop stock; a shop sale draws down the offer. One authoritative stock level, not two panels drifting apart.
- → Cursor-based order ingestion. Orders come from Allegro’s event journal (/order/events) against a persisted lastEventId. Nothing’s lost if anything pauses — it resumes from where it stopped.
- → OAuth, multi-account. OAuth 2.0 authorization-code flow, encrypted token set, refresh-on-401 handled by the adapter. One instance runs several Allegro accounts alongside several shops, each connection holding its own encrypted credentials.
- → Carrier mapping. A ShippingProviderManager maps Allegro’s carriers onto your shipping adapters — InPost and DPD today — so marketplace fulfilment doesn’t mean re-keying data.
HOW IT WORKS
Where the ports came from
Allegro is not a demo integration. Order ingestion, identifier mapping, idempotency, retry classification, rate-limit backoff — the capability ports the whole platform stands on were shaped against this API. ERLI later shipped as an adapter on those same ports without touching the core, which is the evidence that they generalise. If you are writing an adapter, PrestaShop is the package to copy; Allegro is where you look for OAuth and token refresh.
For an agency, that is the interesting part: the marketplace your client needs is an adapter written against a stable plugin SDK. You build the adapters; the foundation is already there. It runs on infrastructure you control, Apache 2.0, no per-order meter.
The step-by-step — registering the Allegro application, OAuth, first offer, first order: Allegro setup guide →
BUILD THE ADAPTERS
A marketplace API that moves under you
In April 2026 Allegro removed an entire API surface — multi-variant offers. If your client’s integration is a private script, a change like that is an emergency. Behind a capability port it was contained in the adapter: fan out one offer per variant, let Allegro group them by GTIN, ship a release.
That is what owning the foundation bought, that time. The plumbing absorbed the change; nothing above the capability port had to move.
HONESTLY
What’s here, and what isn’t yet
OpenLinker is alpha, pre-1.0. Allegro serves the Polish market — if your clients don’t sell there, read this as evidence about the architecture rather than a feature you’ll deploy. The adapter ships with unit and integration tests covering offer creation and the full order path, and it supports Allegro’s sandbox environment, but nothing runs against live Allegro in CI — unlike the WooCommerce adapter, which is E2E-tested against a real WooCommerce in Docker. We’d rather say that than write “fully tested”.
FAQ
Common questions
What is Allegro?
Poland’s dominant marketplace, with roughly 15 million active buyers — for most Polish sellers of physical goods, being on it is not optional. For OpenLinker it is the first and deepest marketplace adapter, and the API the capability ports were designed against.
Is the Allegro integration production-ready?
OpenLinker is alpha, pre-1.0. The adapter covers offer creation and updates (including bulk, where you can re-run just the rows that failed), EAN category matching, GPSR data, seller policies, carrier mapping, and cursor-based order ingestion, with unit and integration tests. Unlike the WooCommerce adapter, nothing runs against a live Allegro in CI. Treat it as early but real.
Can one instance run several Allegro accounts?
Yes. One OpenLinker instance runs multiple Allegro accounts alongside multiple shops, each connection holding its own encrypted credentials. The README’s example: two PrestaShop stores plus three Allegro accounts, one OpenLinker instance.
What happened when Allegro removed multi-variant offers?
In April 2026 Allegro withdrew multi-variant offers along with the API resources behind them. The adapter now publishes one offer per variant and relies on Allegro’s auto-grouping via GTIN and distinguishing parameters. That change landed inside the adapter; nothing above the capability port had to move.
Is there a per-order fee?
Not from us. OpenLinker is self-hosted and open-source (Apache 2.0) — you pay for the server you’d run anyway. Allegro’s own sales commission still applies; that’s the marketplace’s fee, not the integration layer’s.
Try the version you own.
The repo is public, Apache 2.0. The dev stack comes up with a single Docker command.