How to Connect ESL Tags to Items via API

The planogram is updated. Prices are correct in the ERP, correct on the shelf-edge label template, correct in the product master. And yet, three hours later, an aisle still shows the old price — because the electronic shelf label attached to that shelf position is still bound to the item that used to live there. Someone has to walk the aisle with a handheld, scan the tag, scan the item, and repeat a few hundred times.

That manual binding step is the last piece of shelf-edge labeling that resists automation. It doesn’t have to. With the ESL Binding API in the Next Generation Label Printing System (LPSNG), you can associate ESL tags with items programmatically, push item data to the displays through a vendor-neutral JSON interface, and only touch a scanner when something has genuinely gone wrong.

This article walks through the automation end to end: the one-time setup, the pipeline that does the binding, what to monitor, and how to keep it reliable.

One-Time Setup: Preparing Your ESL Environment

You do this once per store, base station, or MDE (mobile data entry) unit. Everything after that is a scheduled job.

1. Register your external system

LPSNG uses a simplified OAuth2 registration protocol: you connect an external system — an ESL base station, a handheld MDE unit, a middleware service — with a single URL. LPSNG manages the token exchange behind that registration, so you don’t implement an OAuth2 client from scratch.

In practice, that means your integration configuration holds one registration URL and a credential, not a token-refresh state machine:

# lpSng-integration.yaml
esl:
  registration_url: "https://lpsng.rsj.de/..."   # from your LPSNG registration
  client_id: "${LPSNG_CLIENT_ID}"
  client_secret: "${LPSNG_CLIENT_SECRET}"        # keep in a secret store, not in git
  store_id: "store-0417"

Store these values in a secret manager. The registration is the one step where a mistake is expensive to unwind.

2. Make sure the hardware is reachable

Your ESL tags need to be installed and in range of their base station or gateway before any API call can succeed. If you’re running CATIC ESL hardware, follow the CATIC installation instructions — antenna placement and tag addressing are the two things that most often cause “the API worked but nothing on the shelf changed.”

3. Confirm your display update path

Display content is updated through the vendor-neutral JSON file interface (ESLSEND). That’s the part worth caring about architecturally: the payload is JSON, not a proprietary binary format, so your integration isn’t welded to one tag vendor. We covered the implications in What a Vendor-Neutral ESL Interface Means for Developers.

4. Point LPSNG at your item data

The binding step needs something to bind to. LPSNG can use Excel files as data and lookup files, a Google Sheets add-on for teams that live in spreadsheets, or your ERP as the upstream source. The binding logic itself doesn’t care — it needs a stable key (SKU or EAN) and the fields you want on the display.

If you want the hard way, you can hand-craft ESLSEND JSON files and run the OAuth2 token exchange yourself. LPSNG’s managed workflow exists so you don’t have to.

The Automated Pipeline: Binding Tags to Items

Here’s the flow, step by step.

Step 1 — Trigger the binding process

The ESL Binding API is a web service built specifically for MDE units that have no web interface: a handheld can call it, a cron job can call it, a webhook can call it. A binding run starts with one HTTP request.

curl -X POST "$LPSNG_BASE/binding/jobs" \
  -H "Authorization: Bearer $LPSNG_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "store_id": "store-0417",
        "source": "erp-sync-2026-10-18",
        "mode": "reconcile"
      }'

The exact path and parameters are in the web service interface documentation; the important part is that a binding run is a job you submit, not a session you sit through.

Step 2 — Let LPSNG map items to tag IDs

This is the step that replaces the scanner. LPSNG takes item identifiers (SKU, EAN) from your data source and matches them to ESL tag IDs, using the tag-to-shelf-position relationship already known to the system. Your code never has to know which physical tag hangs over which shelf.

If you’re driving the reconciliation yourself, the loop is small:

import os, requests

BASE = os.environ["LPSNG_BASE"]
HEADERS = {"Authorization": f"Bearer {os.environ['LPSNG_TOKEN']}"}

def reconcile(store_id: str, items: list[dict]):
    """items: [{"sku": "...", "ean": "...", "price": "...", "name": "..."}]"""
    resp = requests.post(
        f"{BASE}/binding/jobs",
        headers=HEADERS,
        json={"store_id": store_id, "items": items, "mode": "reconcile"},
        timeout=30,
    )
    resp.raise_for_status()
    return resp.json()["job_id"]

Step 3 — Push item data to the displays

Once a tag is bound, LPSNG updates the ESL display with the item-specific values you supply — price, name, barcode, whatever the layout uses — through the ESLSEND JSON interface. A minimal payload looks roughly like this (see the ESL interface docs for the full schema):

{
  "esl_id": "TAG-0042-1188",
  "item": {
    "sku": "SKU-88213",
    "ean": "4012345678901",
    "name": "Organic Coffee 500g",
    "price": "8.49"
  }
}

Because the format is vendor-neutral, swapping tag hardware later is a deployment question, not a rewrite.

Step 4 — Print the labels that still need printing

Some things stay physical: promotional shelf talkers, shelf-edge strips, case labels. Those can be rendered from the same item data, because LPSNG’s web service API can submit print jobs and render single labels as PDF or PNG, and the standalone Player can emit PDF, PNG, JSON, print jobs, or ESL updates from the same package-plus-data input. One data source, two output channels.

The whole thing as a scheduled workflow

A nightly reconciliation is usually enough:

# crontab: every night at 02:15, after the ERP export lands
15 2 * * * /usr/local/bin/python /opt/esl/sync.py --store store-0417 >> /var/log/esl-sync.log 2>&1

# sync.py (sketch)
items = load_from_erp()          # or read the Excel/Sheets export
job_id = reconcile("store-0417", items)
wait_for_job(job_id)             # poll LPSNG for job status
handle_failures(job_id)          # retry or flag

Cron is fine. A webhook from your ERP is better — it binds tags the moment prices change instead of hours later.

Monitoring and Failure Handling

Automation you can’t see is automation you can’t trust.

• Track jobs in the job queue. LPSNG’s job queue is part of the core functionality in every edition. Binding runs and display updates appear there, and failed jobs are logged for review.
• Retry, don’t panic. If a tag is unreachable, the API returns an error. Configure retry logic for transient failures (a tag that’s temporarily out of range) and flag the rest for a human.
• Watch tag health. Battery and signal status are visible through the ESL interface. Polling this is how you find the tag that will die next week instead of the one that already did.
• Alert on your side. Poll the LPSNG web service for job status and push failures into whatever you already use for alerting. You don’t need a second monitoring stack.
• Keep a manual fallback. If a tag stays unreachable, rebind it manually in the LPSNG web UI once it’s back online. The same platform manages both the automated and the manual path, so there’s no split-brain between the two.

A simple status check:

curl -s "$LPSNG_BASE/jobs/$JOB_ID" \
  -H "Authorization: Bearer $LPSNG_TOKEN" | jq '{status, failed: [.results[] | select(.status=="failed")]}'

Best Practices for Reliable ESL Automation

• Keep identifiers clean. Your ERP key and your ESL key should be the same string, generated in one place. Most “binding failed” tickets are really “SKU changed format” tickets.
• Stay on the JSON interface. Vendor-neutral payloads make hardware swaps a deployment task. It also means the same payload structure works across stores.
• Test in staging first. A binding run against a test store catches mapping errors before they hit 400 tags in a live aisle.
• Rotate credentials. Store OAuth2 credentials and refresh tokens in a secret manager, document who owns them, and rotate on a schedule.
• Consider edge deployment. For stores with flaky connectivity, the Embedded Edition runs complete LPSNG on a single-board computer such as a Raspberry Pi, so binding jobs execute locally and sync when the link is up.
• Verify barcodes before you push them. A wrong EAN on a display is worse than a stale price — see How to Verify Barcodes Before Printing Labels.

FAQ

Do I need to write code to connect ESL tags to items?

Not necessarily. LPSNG provides a web service API and a managed workflow that can be triggered via simple HTTP requests. For full automation, though, you’ll likely write scripts that call the ESL Binding API. The vendor-neutral JSON interface (ESLSEND) makes it straightforward to integrate with your existing systems.

Can I use the ESL Binding API with any ESL hardware?

The ESL Binding API is designed to be vendor-neutral, using a JSON file interface (ESLSEND) to update ESL displays. It can work with various ESL hardware as long as they support the JSON format. LPSNG also provides specific installation instructions for CATIC ESL hardware.

How does LPSNG handle authentication for external systems?

LPSNG uses a simplified OAuth2 registration protocol. You connect your external system (like an MDE unit) with a single URL, and LPSNG manages the token exchange. That avoids implementing OAuth2 from scratch in every integration.

What happens if an ESL tag goes offline during an update?

If a tag is unreachable, the API returns an error. LPSNG’s job queue logs the failure, and you can configure retry logic or receive alerts. For critical updates, you can manually rebind the tag using the LPSNG web UI once it’s back online.

Conclusion: Automate Once, Benefit Continuously

Connecting ESL tags to items via API removes the aisle-walking step from your process. You submit a binding job, LPSNG matches your item identifiers to tag IDs, and the displays update through a JSON interface that doesn’t lock you into one hardware vendor. Prices stay accurate between planogram changes instead of drifting until someone notices.

The practical path is the managed one: register each store with a single URL, let Next Generation Label Printing System handle token exchange and job tracking, and keep your own code to the part that’s actually yours — deciding which items go where.

Start by reading the ESL interface documentation and the ESL Binding API reference. Then prototype against the cloud edition, or download the Embedded Edition if you want the binding job running inside the store from day one.

Related posts

• What a Vendor-Neutral ESL Interface Means for Developers
• Cloud Label Printing Software Pricing: What to Look For
• How to Verify Barcodes Before Printing Labels