Shipping and barcode labels from Dynamics 365 Business Central: Labelixa reads your posted sales shipments through the standard API, fills a ZPL template, shows the label on screen and prints it through the DirectPrint agent.
Business Central records the shipment, but the thermal label is printed elsewhere: report layouts do not emit ZPL, a partner extension is expensive to commission, and whether the template is right is only answered once it comes off the printer. What is missing is a layer that reads the fields, shows the label on screen and hands it to the printer.
You create an app registration (client credentials) in your own tenant and enter tenant, environment and company IDs in the Labelixa connector settings. The client secret is stored encrypted and never shown on any screen.
Fields of the `salesShipments` record — ship-to name, address, city, postal code, document number — are mapped to label variables; only mapped fields are requested.
The ZPL built from the mapped data is rendered at real size and the barcode is verified by actually decoding it. A wrong field is visible before any media is consumed.
The finished label goes to a Zebra-class printer on the network or USB through the DirectPrint agent; job history stays in the panel.
This image was produced from the ZPL beside it with the Labelixa engine.
Try your own ZPL code →^XA
^FO25,20^A0N,26,24^FDSHIP TO^FS
^FO25,52^A0N,22,20^FDTrey Research^FS
^FO25,80^A0N,20,18^FD153 Thomas Drive^FS
^FO25,106^A0N,20,18^FDChicago 61236^FS
^BY2,3,80^FO25,140^BCN,80,Y,N,N^FDS-SHPT102001^FS
^FO470,20^BXN,5,200^FDS-SHPT102001|Trey Research^FS
^XZShipment and document numbers
SYMBOLOGYData MatrixCarton and parcel labels, small area
SYMBOLOGYITF-14Case and pallet outer packaging
Shipment headers are read through the standard Business Central API v2.0 (`companies/{id}/salesShipments`); the query requests only the mapped fields. Measured against a real BC environment: a 42-field record, pages of 200 records.
The integration only reads. A "label printed" status is not written to Business Central; that needs a small AL extension on the customer side and is shaped together with the pilot. Nothing that does not work is promised.
One call processes at most 200 records and reports whether more exist; fetching a single shipment by filter (document number) is the typical use. The response cap is 1 MB; exceeding it returns a clear error.
The client secret lives in an AES-256-GCM encrypted column and never reaches a read surface; outbound requests pass scheme, IP and redirect checks; tokens and customer data are not logged.
Only Business Central online (api.businesscentral.dynamics.com) has been measured so far. The on-premises OData endpoint needs its own verification and is not promised before it is measured.
Connectors are available on Pro and higher plans; a connector setting belongs to an API key and is managed from the panel.
Not yet. Today the flow is started from Labelixa (API or panel). The in-BC app (AppSource) is on the roadmap and is shaped with a pilot partner.
Yes, from posted sales shipments: ship-to name, address, postal code and document number are read through the standard API and placed on a ZPL label — for example a 4×6 shipping label with a Code 128 barcode — then printed through the DirectPrint agent on a Zebra-compatible thermal printer.
Any symbology the Labelixa engine renders, including Code 128, GS1-128, Data Matrix, QR and ITF-14. The barcode is decoded on screen before anything is printed.
No. Today's integration reads the data through the standard Business Central API with an Entra app registration; nothing is installed inside BC.