How ESLs Integrate With Your POS, ERP & E-Commerce

If you are the person who has to sign off on whether electronic shelf labels will actually work with your stack, the e-paper screen is the least of your concerns. The real question is whether a label network can read from your POS, your ERP and your online shop without you re-platforming anything — and how much of that work lands on your team. This article walks through how the integration is built, what it plugs into, how the data flows, and the questions that separate a clean project from a painful one.

Why integration — not the label — decides whether the project succeeds

Integration is where ESL projects are won or lost, because a label is only ever as correct as the data feeding it. The hardware is a solved problem: pick a reputable label and it will display whatever it is told for years. What varies enormously between projects is whether the price, promotion and product data reaches the shelf reliably, in the right format, without anyone maintaining a fragile export by hand. A pilot of fifty labels hides this; a fleet of fifty thousand across many stores exposes it immediately. So evaluate the connection to your systems first and the screen second.

The sync engine: how it sits between your systems and the shelf

The piece that makes ESLs work is a sync engine — a service that sits between your systems of record and the label network. Your data flows in on one side; the engine resolves what changed, figures out which labels are affected, and pushes the new image to those labels through in-store access points on the other side. You never talk to individual labels, and your source systems never talk to the shelf. They only ever talk to the engine.

This middle layer is what keeps the integration shallow. Your POS does not need to know what an access point is; your ERP does not need a plugin per label model. They hand off prices and product data the way they already export data, and the engine does the translation, batching, retries and fan-out to thousands of screens. You can see this shape in our integration diagram: database, POS, ERP and e-commerce feed the Synchro sync engine, which updates labels in every store.

What it connects to — POS, ERP/SAP/Oracle/Dynamics, databases, e-commerce

The engine connects to wherever your prices and product data already live — you keep your current systems and nothing migrates. In practice that means one or more of:

Point of sale. The till is often the most authoritative source of the selling price, so syncing from POS keeps shelf and checkout identical by construction. Cloud POS platforms (for example Odoo or Hiboutik) typically expose this over an API; on-premise tills usually expose it as a database view or a scheduled export.
ERP — SAP, Oracle, Microsoft Dynamics and similar. When pricing, promotions and master data are governed in the ERP, the engine reads from there. These systems are built to integrate: SAP via IDocs/BAPIs or its OData and REST services, Oracle through its REST and integration layers, Dynamics 365 via its Web API and Dataverse. You expose the price and article entities you already report on; you do not build anything ESL-specific inside the ERP.
Databases and flat files. If the real source of truth is a SQL database or a nightly CSV/XML drop, the engine reads that directly. This is common and perfectly robust — many large fleets run on a scheduled file feed.
E-commerce platforms. Connecting your online catalog (Shopify, Magento/Adobe Commerce, WooCommerce, a headless commerce API) lets the same price govern the website and the shelf, which is the foundation of online–offline price parity.

The point is not a long logo wall of pre-built connectors. It is that the engine meets your data in whatever form it already exists — API, database, or file — rather than forcing you onto a new platform.

How integration actually works: APIs, middleware, batch vs near-real-time

Mechanically there are two patterns, and most real deployments use a mix of both. The right one depends on how fast a price change has to reach the shelf, not on a preference.

Near-real-time, via API or webhooks. When a price changes in your system, it calls the engine (or the engine subscribes to a change feed), and the affected labels redraw within seconds. This is the right pattern for dynamic pricing, flash promotions and competitive repricing.
Batch / scheduled sync. The engine pulls a full or delta export on a schedule — every night, every hour, every few minutes. This is simpler to build, easy to audit, and entirely adequate when prices change on a predictable cadence. A nightly batch updates the whole fleet before doors open.

The middleware in the middle absorbs the messy reality between those two idealized pictures: it deduplicates changes, retries failed pushes, queues updates when a store's network blips, and reconciles so that a label that missed an update gets corrected on the next pass. That resilience is the whole reason you do not connect your ERP straight to the shelf.

One-time integration vs ongoing data flow: once vs never again

The integration is a one-time build; the data flow afterward is automatic and hands-off. It helps to separate the two clearly:

Once: you grant access to a data source (an API credential, a read-only database user, or a drop folder), and you agree on the field mapping. We map your data and build the bridge from your stack to the label network — no migration and no new tools for your team to learn.
Never again: from go-live, a price change in your system propagates to the shelf on its own. Nobody exports a file by hand, nobody walks the aisles with a label gun. Your staff keep working in exactly the systems they already use; the labels are downstream.

That division is the answer to the question most IT leads are really asking: the effort is concentrated up front and bounded, not a standing operational burden.

Data mapping: what the engine needs from you

The substance of the one-time work is data mapping — telling the engine which of your fields means what. There is no magic here, and it is the part worth getting precise about during scoping. At minimum the engine needs:

A stable product key (SKU/EAN/GTIN). This is the anchor that ties a physical label to a row in your data, so it must be unique and unchanging. Most integration friction traces back to an unstable or inconsistent product identifier.
Price fields. The regular price, plus any other prices you display — member price, unit price (per kg/L), tax-inclusive vs exclusive — and which one is authoritative when systems disagree.
Promotion data. The promo price plus its start and end timestamps, so the label can switch to the promotion layout on time and switch back by itself when it ends.
Product attributes you want on the label: name, brand, size, origin, nutritional or regulatory text, QR/loyalty codes.
Stock fields, if you want availability or low-stock state shown on the shelf edge.

Cleaner master data makes for a faster integration. If your SKUs are consistent and your prices live in one governed place, mapping is quick; if pricing is scattered across spreadsheets and overrides, that is worth tidying before — or as part of — the project.

Two-way data: pushing stock and pick info back from the shelf

Integration does not have to be one-directional. Modern labels carry an LED and a button, and the engine can send signals back into your systems as well as out to the shelf. A picker can press a label to confirm a pick or flag a stockout, and that event flows back to your inventory or order-management system; a click-and-collect order can flash the labels for the items on the list so staff find them in seconds. The principle is the same as the outbound path — your systems talk to the engine, the engine talks to the labels — just in reverse. Treat two-way flows as a phase-two capability: most rollouts prove the outbound price sync first, then add return signals once the basics are solid.

What to ask a vendor about integration effort and connectors

Ask vendors how they connect to your specific systems and who does the work — vague claims of "integrates with everything" are a red flag. A short, sharp checklist:

How do you connect to our exact POS / ERP — by API, database, or file — and is there a pre-built connector or a custom build?
Do you support near-real-time sync, scheduled batch, or both, and what is the typical end-to-end latency from a price change to the label?
What access do you need from us, and what is read-only vs read-write?
Who owns the integration build and ongoing maintenance — you, us, or a third party — and what happens when our ERP is upgraded?
How do you handle missed updates and reconciliation, so a label can never silently show a stale price?
What does the field mapping look like, and how do you handle promotions with start/end times and multiple price types?
What is the realistic timeline and what is expected of our team during it?

The quality of the answers — specific to your stack, honest about effort — tells you more about a vendor than any spec sheet. For the broader buying criteria beyond integration, the ROI framework and the ESL vs. paper comparison cover the cost and operational side, and the ESL guide covers the fundamentals.

See it mapped to your own systems

The fastest way to de-risk feasibility is to put your actual stack on the table. In a demo we will map your POS, ERP, database and e-commerce to the sync engine, show you which connection pattern fits, and give you a clear picture of the one-time effort — so you can approve the project knowing exactly what your team has to do, and what they never will again.