The ZKong cloud platform receives price and product data from your existing systems. There are three integration methods, and the right one depends on the system you're sourcing data from. Below is exactly how each works, what data we need, and how to confirm compatibility with your stack.
How ESL data integration works
ESLs don't replace your point-of-sale or ERP. They subscribe to the price and product data those systems already produce. The ZKong cloud platform pulls in that data and pushes it out to every label in every store.
There are three established ways to get data into the platform. Pick whichever fits how your current stack already exposes data.
REST API push
Your POS or ERP makes an HTTPS POST to our API endpoint each time a price changes. Updates appear on the shelf within seconds.
Best for: cloud-native POS systems with webhook support, or any system where engineering can call a REST endpoint.
Scheduled CSV / SFTP
Your system drops a daily (or hourly) CSV onto a secure SFTP server we provide. The platform ingests on schedule.
Best for: on-premises POS systems, ERPs that already produce nightly export files, or stores without dedicated IT.
Manual upload via web UI
Upload an Excel or CSV file directly through the cloud platform's web interface. No engineering required on your side.
Best for: small pilots, single-store deployments, or stores doing manual price management already.
What data the platform needs
Whichever method you pick, the platform needs the same fields per SKU. The minimum set is small:
- SKU code (or internal product ID) — primary key for matching ESL to product
- Barcode (UPC, EAN, or GTIN) — for shopper QR-code lookups and re-pairing
- Product name / short description — what shows on the label
- Regular price — the price that displays
- Sale / promo price (optional) — triggers promotional ESL templates if set
- Unit of measure (e.g. "per lb", "per oz") — appears next to the price
- Category (optional) — for grouping templates by department
Anything beyond this — stock levels, ratings, custom fields — can be added if your system exposes it. The platform stores arbitrary key-value pairs per SKU and you choose which ones appear on each label template.
Common US POS & ERP systems
Below is the short list of US retail systems we've seen customers ask about most often. The status column is conservative — we mark a system "Confirm with us" until we've actually deployed it for a customer in production. If yours isn't listed, that does not mean it's incompatible — it usually just means a custom integration scoping call.
| System | Type | Common integration method | Status |
|---|---|---|---|
| Square for Retail | Cloud POS | REST API (webhook on item update) | Confirm with us |
| Lightspeed Retail (X-Series, R-Series) | Cloud POS | REST API or scheduled CSV | Confirm with us |
| NCR Counterpoint | On-prem POS | SFTP nightly export | Confirm with us |
| Toast | Restaurant POS | REST API (menu sync) | Confirm with us |
| Clover | Cloud POS | REST API or CSV | Confirm with us |
| Shopify POS | Cloud POS | REST API (product webhooks) | Confirm with us |
| Revel Systems | Cloud POS | REST API or CSV export | Confirm with us |
| SAP for Retail | Enterprise ERP | SFTP / IDoc batch | Confirm with us |
| Oracle Retail (RMS / Xstore) | Enterprise ERP | SFTP nightly batch | Confirm with us |
| Microsoft Dynamics 365 Commerce | Enterprise ERP | REST API or scheduled export | Confirm with us |
| Cybex (custom POS) | On-prem grocery POS | Direct DB pull or SFTP | Confirm with us |
| Bizerba (deli scales) | Weight-based pricing | SFTP or local network sync | Confirm with us |
| Manual / spreadsheet | None | Web UI upload | Works out of the box |
| Custom / internal system | Proprietary | REST API or SFTP | Custom scoping |
"Confirm with us" means we have not personally deployed this integration for a US customer yet. We can usually validate compatibility within a 30-minute scoping call — most modern POS systems can produce a CSV export, which is sufficient.
Cannabis-specific: Metrc + dispensary systems
For cannabis dispensaries, the ESL platform pulls inventory data derived from Metrc rather than directly from Metrc. The typical chain is:
- Your dispensary POS (Dutchie, Treez, Flowhub, BLAZE, Cova, Greenbits, etc.) reconciles with Metrc on its own schedule.
- The same POS exposes price + product data to ESL via the methods above (most use REST API or CSV).
- THC content, strain, batch ID — all flow through the dispensary POS as standard fields.
If your dispensary POS isn't on the table above, the same "Confirm with us" rule applies. Most cannabis-vertical POS systems can output a product feed.
Pharmacy: NDC, Class III, and price transparency
For pharmacy ESL deployments, the platform syncs from your pharmacy management system (PMS) — McKesson EnterpriseRx, ScriptPro, Computer-Rx, RxOne, etc. National Drug Code (NDC) is treated as the SKU. For Class III display accuracy requirements, the platform writes a confirmation log per update so you have an audit trail per label.
What integration scoping looks like
If you want to confirm your specific stack works, the scoping call covers four questions:
- What system holds your master price + product data? (POS, ERP, spreadsheet, etc.)
- How does that system currently expose data? (API, CSV export, manual entry only)
- How often do prices change? (daily, weekly, real-time during promotions)
- How many SKUs per store, and how many stores? (drives the integration method choice)
Most calls end in 20-30 minutes with a clear path. We don't charge for scoping.
Confirm your system works with ZKong ESLs
Tell us what POS or ERP you're running. We'll either confirm a known integration path or scope a custom one — usually within a single call, no obligation.
Request integration scoping →