No ZPL. No developer. No ticket.
A drag-and-drop warehouse label designer that outputs ZPL.
Managers place text, barcodes and live data tokens on a canvas; the renderer turns it into Zebra dot coordinates and the preview is what prints.
Three weeks to move a text box four millimetres.
A customer wants their part number on the carton label. In most warehouses that is a support ticket, a developer, a change window and three weeks — for moving a text box four millimetres.
The people who know what belongs on the label are never the people allowed to change it.
Illustrative only. A layout change goes live the moment it's saved — no deploy, no version conflict. Every label printed carries the template version that was live when it fired, so a reprint months later reproduces exactly what shipped, not what the template looks like now.
A canvas, not a code editor.
Drag-and-drop canvas
Text blocks, barcodes, QR codes, lines and boxes are placed, resized and repositioned on a Fabric.js canvas. No ZPL is written at any point.
Set the stock in inches
Width and height are set at template creation; the renderer translates canvas positions to Zebra dot coordinates for that stock. No manual DPI maths.
Code 128, Code 39, UPC-A, UPC-E, EAN-13, QR Code and Data Matrix are all supported — every standard warehouse symbology. Templates can be duplicated within the designer; import from external sources is not currently supported.
There is no wrong field to bind.
- Context-aware field palette The designer reads the label type being built and offers only the fields that exist in that context. A receiving label offers PO number, lot and vendor. A bin label offers zone, aisle, rack and level. There is no wrong field to bind.
-
Token binding
Fields bind with a simple token syntax —
{{item_code}},{{lot_number}},{{lp_barcode}}— and the token engine merges live workflow data at print time. - Barcodes bind the same way Scan the printed label and it returns the live value — LP number, bin code, tracking number — not placeholder data.
The preview is the same renderer.
WYSIWYG PDF preview. The browser preview uses the same PDF renderer that produces audit copies, so what is on screen is what comes off the Zebra.
The ZPL path and the PDF path come out of one template JSON. See how labels print.
Designing a template is not deploying it.
Template versioning
Every save increments the version and the library keeps the history.
Snapshot at print time
PrintJob records store the template as it was when it printed, so a label from eight months ago reproduces exactly however many times it has changed since.
Why that matters for an auditType classification
Templates are classified product, LP, bin, staging, carton, outbound pallet or custom, and the classification controls which templates a module can select.
Library and active/inactive control
Deactivating a template stops it firing on its events immediately, with no orphaned jobs and no cleanup, and historical PrintJob records that reference it stay intact. Design and deployment stay separate: designing a template does not deploy it.
Designer access is available to any portal user with the Label Management permission, configurable per role. There is no approval workflow — the label manager controls publishing directly.
Never printed from an export that is already stale.
The tokens on a label bind to live warehouse data that came from Acumatica by webhook — item descriptions, lot numbers, PO numbers, UOM — so a label is never printed from an export that is already out of date. Change an item description in Acumatica and the next label carries it. No re-mapping and no re-publishing of the template.
Twenty minutes, a live canvas, ZPL out to a real Zebra.
Token binding included. No slides. We sell through Acumatica VARs — tell us how your floor runs and we will introduce you to the right partner.