Label Design Software Buying Guide for System Integrators

If you are a system integrator, “which label design software should we embed?” is a buying decision long before it becomes a technical one. You are not shopping for a desktop label editor for a single office printer — you are choosing a rendering and printing backend that your own application will call, resell, or ship inside a device. That changes the evaluation criteria completely: the feature list matters less than the deployment model, the integration surface, the upgrade path, and the total cost of ownership over the next few years.

The alternative to buying is building. Building looks cheap on day one and expensive on day 400, because a label pipeline is not one feature — it is a pile of them:

• 1D and 2D barcode rendering that must stay correct for every symbology your customers ask for.
• PDF generation with exact physical dimensions, bleed, and rotation.
• Printer communication and driver quirks across thermal, laser, and office devices.
• Electronic shelf label (ESL) support if any of your customers run retail.
• Ongoing maintenance every time a customer adds a new label, a new data source, or a new printer.

Next Generation Label Printing System (LPSNG) is a managed label design and printing platform that packages all of the above behind a web service API, a simplified OAuth2 registration model, and several deployment editions. This guide is about evaluating it — or any comparable platform — as a purchase: what each tier gives you, what the real cost drivers are, and how the upgrade path works. We deliberately stay away from a feature-by-feature shootout; that comparison is a different article, and a shorter one.

What You Get at Each Tier: Editions and Deployment Models

LPSNG is the same core product in every edition. What changes is where it runs and who it serves.

Cloud Solution

The hosted multi-user cloud edition. You register your external system, authenticate, and start submitting jobs — no server, no OS maintenance, no update cycle of your own. For an integrator validating a new vertical or onboarding the first customer, this is the lowest-friction starting point.

Embedded Edition

Complete LPSNG on a single-board computer such as a Raspberry Pi. This is the option for production floors, warehouses, and retail back offices where the printing must keep working when the internet does not. You own the hardware and the network path; the software stack is the same product you already integrated against in the cloud.

Enterprise Features

Multi-user, multi-region, and multi-device capabilities for corporate environments. This is the tier that matters when your integration stops being a single-site pilot and starts being a rollout across countries, shifts, and device fleets.

White Label Solution

A tailored user experience for printer manufacturers, paper manufacturers, and system integrators who need to present the label design software as their own. If your business model is “our portal, our brand, our labels,” this is the tier to price against your own product margin rather than against a utility bill.

LPSNG Player

A standalone command-line print engine with a deliberately small contract: a label package plus data goes in; PDF, PNG, JSON, direct print output, or ESL output comes out. It is useful when you want batch rendering or a headless pipeline step without driving the full web UI.

Cost/Benefit and ROI: Evaluating the True Price of Integration

The honest way to price a label platform is to price the alternative. Ask your team what it would cost to build and then maintain the following, and compare that to a managed service:

• Barcode rendering for the 1D and 2D formats your customers request.
• A PDF renderer that respects physical label geometry.
• Printer communication across the devices your customers already own.
• An ESL path, if retail is anywhere on your roadmap.
• Data plumbing for every customer’s spreadsheet, ERP export, or CSV.

None of those line items disappear when you buy — they move. The difference is who carries the maintenance burden when a symbology changes, a printer firmware update lands, or a new ESL vendor appears.

Upfront licensing vs. development hours. A licence fee is a known, budgetable number. Development hours are not: they arrive as a slow trickle of “just one more barcode format” tickets that never fully close. When you compare the two, compare them over a realistic horizon — three years is a fair planning window for an embedded component.

Operational cost: cloud vs. embedded. The Cloud Solution moves hosting to the provider, which means no hardware to buy, patch, or replace. The Embedded Edition moves it back to you: you supply the single-board computer, the power, the network, and the person who walks over when something stops. Both are legitimate; the choice usually comes down to network reliability at the print location and whether your customer’s compliance rules allow a hosted service.

Time-to-market. This is usually the deciding factor. The LPSNG integration surface is a web service API plus a simplified OAuth2 registration flow, which means the first end-to-end job — authenticate, submit, render, print — is a matter of days of developer time rather than a multi-month build. If your revenue depends on shipping the integration this quarter, that difference dwarfs any plausible licence delta.

Scalability without re-architecture. Enterprise Features cover multi-user, multi-region, and multi-device scenarios. Buying into that capability early is cheap; bolting it onto a homegrown printing service after your third country goes live is not.

Less custom data preparation. Two integrations cut glue code you would otherwise write and maintain: the Google Sheets Add-on for creating layouts and printing directly from a spreadsheet, and the Excel interface for using Excel files as data files and lookup files. There is also an Excel Add-In with 3D visualization of packing solutions that imports item and container data and exports the packing plan.

Pricing itself is not published in the product documentation, so treat the numbers as a request-for-quote step and evaluate the tiers structurally first.

Upgrade Path: Self-Hosted vs. Cloud and Scaling Your Integration

The reason the tier list above is a path and not a menu is that all editions share the same core functionality: web UI, label studio, job queue, PDF generation, and the web service interface. Your integration code does not get rewritten when you move.

A typical progression looks like this:

1. Start on the Cloud Solution. Prototype against the hosted multi-user edition. Validate that the label studio produces the labels your customer actually wants, and that your job submission flow works end to end.
2. Move to the Embedded Edition when the site demands it. On-premise control, edge deployment, or a network you do not trust. The label packages and the API surface you already built move with you.
3. Add Enterprise Features when the rollout grows. Multi-user, multi-region, and multi-device support arrive as configuration and capacity, not as a rewrite.
4. Go White Label when the product becomes yours. If you are selling label design software under your own brand, the tailored user experience belongs in your commercial model from the start.

The practical takeaway for a buying decision: you can commit to the smallest tier that solves today’s problem without committing to a dead end.

Integration Capabilities That Matter for System Integrators

When you evaluate any label platform, this is the checklist to run against it. Here is how LPSNG maps onto it.

Web Service API

The API covers the operations an integrator actually needs: submit print jobs, render a single label as PDF or PNG, and direct print. The same interface carries the OAuth2 authentication model. The exact endpoint paths and payload schemas live in the web service interface documentation; the shape of the flow is:

export LPSNG_API="https://lpsng.rsj.de"   # or your Embedded Edition host

# 1. Register / authorize once via the simplified OAuth2 flow
#    (see the OAuth2 documentation for the registration URL)

# 2. Submit a print job: label package + data in
curl -s -X POST "$LPSNG_API/<print-job-endpoint>" \
  -H "Authorization: Bearer $LPSNG_TOKEN" \
  -H "Content-Type: application/json" \
  -d @job.json

# 3. Render a single label instead of printing
curl -s -X POST "$LPSNG_API/<render-endpoint>" \
  -H "Authorization: Bearer $LPSNG_TOKEN" \
  -H "Content-Type: application/json" \
  -d @one-label.json --output label.pdf

Replace the placeholder paths with the ones from the documentation — the point is that both operations are a single authenticated POST. A full walkthrough of the calls is in How to Print Labels From a Web Service API: A Developer Walkthrough.

OAuth2 Registration

LPSNG uses a simplified OAuth2 registration protocol whose job is to connect an external system — an ESL base station, for example — using a single URL. For integration work this is significant: authorization becomes a configuration step rather than a bespoke token-handling subsystem you have to build, test, and rotate.

Field Script API

You can attach Python script blocks to label fields to access and modify field values before printing. That is where per-customer business rules live without touching your application code — trimming a supplier name, deriving a lot code, or defaulting an empty field:

# Field Script API — illustrative pseudo-code; see the Python API reference
# for the exact field object exposed to script blocks.
value = field.value

if not value or not value.strip():
    field.value = "N/A"
else:
    field.value = value.strip().upper()

Full reference: Python API.

Electronic Shelf Labels

The ESL story is two interfaces. A vendor-neutral JSON file interface (ESLSEND) updates ESL displays, and a web service (the ESL Binding API) binds tags to items, specifically aimed at MDE units that have no web interface of their own. A payload oriented at the file interface looks roughly like this — the documented schema is the authority:

{
  "type": "ESLSEND",
  "labels": [
    { "tag": "A-1024", "item": "<item-id>", "price": "<price>", "currency": "EUR" }
  ]
}

See ESL Interface for the schema and ESL Binding API: Documentation and Examples for binding workflows.

Reusable Sidebar

An embeddable sidebar lets you place LPSNG’s label UI inside another web application instead of sending users to a separate tool. For integrators building a portal, that is often the difference between “a printing feature” and “a printing product”.

Barcode Formats

1D and 2D formats are supported across the platform, which is the requirement you should test first against your customer’s existing label stock — see Barcode Formats.

Use Cases and Fit: When to Choose LPSNG

LPSNG fits where labels are a component of someone else’s process, not the product itself.

• Order-specific labeling for fulfillment. Customer- and product-specific labels generated per order, driven from your order system through the web service API.
• Packaging lines. Traceability and international packaging with multi-device support — the Embedded Edition case, where the line must keep printing.
• Retail. Electronic shelf labels for dynamic pricing, using the JSON file interface for display updates and the binding service for tag-to-item assignment.
• Cross-industry. Anything that needs professional-looking labels without a development project behind them.

In all of these, the operating model is the same: LPSNG is a managed service. You connect your application, send data, and the platform handles label rendering and printing. Your engineering time stays on your own product.

FAQ

How does OAuth2 simplify connecting external systems?

LPSNG uses a simplified OAuth2 registration protocol that connects external systems (e.g. ESL base stations) with a single URL, reducing the complexity of authentication and authorization. Practically, that means one registration step instead of a custom token exchange.

Can I use LPSNG on a Raspberry Pi?

Yes. The Embedded Edition provides complete LPSNG on a single-board computer such as a Raspberry Pi, which makes it suitable for on-premise or edge deployments where you want the printing stack close to the devices.

What is the difference between Cloud and Embedded editions?

The Cloud Solution is a hosted multi-user cloud edition, while the Embedded Edition runs on a single-board computer on your own premises. Both share core functionality — web UI, label studio, job queue, PDF generation, and the web service interface — so an integration built against one carries over to the other.

How do I integrate ESL tags with LPSNG?

LPSNG offers a vendor-neutral JSON file interface (ESLSEND) to update ESL displays and an ESL Binding API to bind tags to items, especially for MDE units that have no web interface. If you are comparing ESL plumbing approaches, see Understanding Electronic Shelf Label Integration APIs.

Conclusion: Making the Buying Decision

Four criteria decide this purchase:

• Deployment model — hosted cloud, embedded on a single-board computer, or both over time.
• Integration effort — a web service API and a single-URL OAuth2 registration versus a build project of your own.
• Scalability — multi-user, multi-region, and multi-device support available as an upgrade rather than a re-architecture.
• Branding — whether the label software has to look like your product or can look like a platform component.

Score those four against your roadmap, then validate with the lowest-commitment option: start on the Cloud Solution, ask what trial access is available, and run one real label job end to end before you sign anything.

Next Generation Label Printing System is the practical answer for most integrators, because it keeps the expensive parts — rendering, barcodes, printer communication, ESL — behind a managed API you integrate once. Start with the documentation, pick your edition, and ship the first label this week.

Related posts

• How to Print Labels From a Web Service API: A Developer Walkthrough
• Zebra Designer Alternative: Label Printing Software to Compare
• ESL Binding API: Documentation and Examples