API Reference

Labelixa REST API reference: render and barcode endpoints, request/response headers, error codes and API-key authentication.

Authentication

The free tier works without a key (IP-based limit); no plan adds a watermark to the output. Send the key in the X-API-Key header; it raises the limits. The ?key= query parameter still works but is deprecated (sunset 2027-01-31): query strings leak into browser history, Referer headers, proxy logs and shared links. Requests using it receive Deprecation and Sunset response headers.

Anonymous (keyless) requests are counted per IP address (IPv6: per /64 prefix) — everyone behind that address shares one bucket: 5,000 labels and 10,000 requests per calendar month (UTC), a daily ceiling of 5,000 labels, 3 requests per second, up to 50 labels per request. A free account (labelixa.com/panel) gets an API key with its own monthly quota, independent of the IP, and can save labels; paid plans raise the limits.

API stability

Inside /v1 we only add: new response fields, new optional parameters and new endpoints can appear at any time, so ignore fields you do not recognise. A breaking change — a field removed or renamed, a type or meaning changed, an error code redefined — ships as a new major version running alongside this one. When an endpoint or an auth method is withdrawn you get at least six months' notice, Deprecation and Sunset headers carrying the removal date, and afterwards 410 Gone plus a pointer to the replacement — never a silent 404. This is a contractual commitment, not a habit: Terms of Service §24.4.1. The commitment covers the endpoints documented on this page. Other paths under /v1 may answer as well; those exist for internal flows, carry no stability promise and can change without notice — build your integration on the documented endpoints only.

Quick start

1. Send one ZPL label to the anonymous endpoint — no key needed, the free quota is enough:
   bash

   curl -X POST "https://api.labelixa.com/v1/printers/8dpmm/labels/4x6/0" \
     -H "Content-Type: text/plain" \
     --data-binary '^XA^FO50,50^A0N,40,40^FDHello^FS^XZ' \
     -o label.png

2. The PNG you get back is the label. Send the same body with Accept: application/pdf to receive a PDF instead.
3. Create an account and add the X-API-Key header to get your plan's quota and rate limit; details in the sections below.

Endpoints

Request headers

Response headers

Error codes

For the Barcode API, invalid data is returned as an image together with HTTP 200 (for no-code tool compatibility) and the detail is given in the X-Warnings header.

Errors and how to fix them

Every error is an HTTP status code plus a body. Read the status first, then the body: render endpoints answer with ONE LINE OF PLAIN TEXT, every other endpoint with JSON whose message is in hata (English). Some JSON bodies also carry a stable machine-readable name — kod (snake_case) or hata_tipi (PascalCase) — and those names are wire values: branch on them, never on the sentence. The Response field names section explains why the key names are Turkish. The table below lists the errors integrators actually meet, when each one happens and what fixes it.

401 / 403 — key, origin, plan, scope, Business Central

{"hata": "Invalid API key", "kod": "gecersiz_anahtar"}

{"hata": "X-API-Key required"}

{"hata": "Access denied", "kod": "origin_kapisi"}

{"hata": "This feature (webhook) is not available on the free plan. See the /v1/plans endpoints to upgrade."}

{"hata": "This key does not have the 'etiket_yaz' scope", "kod": "kapsam_yok", "gereken_kapsam": "etiket_yaz"}

{"hata": "The billing portal can only be opened with the account's primary key or a panel session", "kod": "birincil_gerekli"}

{"hata": "Role 'viewer' is not allowed to perform 'etiket_yaz'", "kod": "rol_yetkisiz", "gereken_eylem": "etiket_yaz"}

{"hata": "Saved labels require an account; a free account is enough (POST /v1/accounts).", "kod": "hesap_gerekli"}

{"hata": "Invalid Entra token: signature verification failed", "hata_tipi": "EntraJetonuGecersiz"}

{"hata": "This Entra tenant is not linked to a Labelixa account; run Connect Account with an API key first", "hata_tipi": "EntraEslemesiYok"}

{"hata": "This Entra tenant is linked to more than one Labelixa account; connect with an API key", "hata_tipi": "EntraBelirsiz"}

{"hata": "This tenant/environment/company is linked to another account", "hata_tipi": "KiraciBaskasinin"}

400 / 404 / 413 / 422 — parameters, size, validation

dpmm must be 6, 8, 12 or 24

Label size must be at most 15 inches

{"hata": "Not found"}

Request body exceeds the 1 MB limit

At most 20000 commands per label (23417 found). Split the ZPL stream into several labels or simplify it.

At most 50 labels per request (120 sent). Upgrade your plan for a higher limit.

{"detail": [{"type": "json_invalid", "loc": ["body", 1], "msg": "JSON decode error", "input": {}}]}

{"hata": "Quick batch accepts at most 20 rows; for more, use a Pro bulk job (/v1/bulk/jobs)", "kod": "satir_tavani", "tavan": 20, "satir_sayisi": 21}

{"hata": "An account with this email already exists", "kod": "eposta_kullanimda"}

402 / 429 — rate limit vs. daily and monthly quota

Per-second request limit exceeded (3/s). Starter: 5/s, 9 USD/month -> https://labelixa.com/pricing?amac=kota

Daily quota insufficient: 3 operations left, this request needs 5 (daily 5000). Upgrade your plan to continue. Next plan: starter, 9 USD/month -> https://labelixa.com/pricing?amac=kota

Monthly label quota insufficient: 40 labels left, this request needs 50 (monthly 20000). The quota renews on 2026-11-17T00:00:00Z; upgrade your plan to continue.

{"hata": "Too many account creation attempts; try again later", "kod": "hiz_siniri"}

{"hata": "Saved label limit reached (5/5)"}

{"hata": "Free DirectPrint trial used up (25 labels). Upgrade to Starter or higher to continue.", "hata_tipi": "DenemeDoldu"}

{"hata": "This tenant's monthly BC print cap (500) is reached", "hata_tipi": "TavanDoldu"}

Two different limits share the 429 status and the headers tell them apart. The per-second rate limit answers with Retry-After: 1 and NO X-Quota-Reason header: wait one second and send the request again. The daily or monthly quota answers with Retry-After: 3600, X-Quota-Action and X-Quota-Reason (gunluk, aylik_etiket or aylik_istek); X-Quota-Reset gives the exact UTC renewal time and retrying before it is pointless — upgrade the plan (the next plan and its address are machine-readable in X-Quota-Next-Plan and X-Quota-Upgrade-Url) or wait for the reset. Anonymous 200 responses add X-Quota-Hint once 150 of the 5,000 free labels are used: a free key gives you your own quota.

409 / 412 / 428 — concurrency and retries

{"hata": "If-Match is required (prevents lost updates)", "guncel_surum": 7, "etag": "\"7\""}

{"hata": "The label changed in the meantime (version mismatch)", "guncel_surum": 8, "etag": "\"8\""}

{"hata": "Same Idempotency-Key but a different request"}

{"hata": "A previous request with the same Idempotency-Key is still being processed"}

5xx — render budget and service

Render time limit exceeded

Service temporarily unavailable

{"hata": "Unexpected server error"}

Print job error types

A print job that fails does not fail the HTTP request — POST /v1/print answered 202 and the result is in the job status. The hata_tipi field of a failed job is one of these classes; asama says how far the job got before it failed.

Response field names

JSON response bodies use stable wire names for their keys. Most of them are Turkish words (for example ozet, mesaj, durum) and they stay exactly as they are: renaming a key would be a breaking change, which the API stability commitment above rules out inside /v1. The official integrations — the MCP server and the n8n node — translate the keys and show English names. The table below is generated from the same mapping they use, so raw responses and integration output can be read side by side. A key that is not listed keeps its JSON name in the integrations too. Error bodies carry the human-readable message, in English, in hata. When each error happens and how to fix it: Errors and how to fix them.

Fixed values

Some fields hold one word from a fixed set. The JSON value stays as it is; the integrations show the English word. Paths use the English field names from the table above; [] marks an array element and * any key.

Bulk job states

The durum field of a bulk job is one of:

Compatibility levels

The compatibility check returns a risk level in risk.seviye, never a guarantee:

onizleme_kapsami groups the label's commands by what OUR preview does with them. It describes the preview, not the printer:

Data extraction (JSON)

If you send Accept: application/json to the render endpoint, the visible text and barcode fields on the label are returned as JSON together with their coordinates (barcodes are marked with tur: barkod):

curl -X POST "https://api.labelixa.com/v1/printers/8dpmm/labels/4x6/0" \
     --data "^XA^FO50,60^FDHello^FS^XZ" -H "Accept: application/json"

ZPL conversion (application/zpl)

With Accept: application/zpl your ZPL is reformatted (each command on its own line; disabled with X-Formatter: Off) and, if X-Target-Dpmm is given, the coordinate/size parameters are scaled from the source resolution to the target. Data fields (^FD) do not change.

curl -X POST "https://api.labelixa.com/v1/printers/8dpmm/labels/4x6/0" \
     --data-binary @label.zpl -H "Accept: application/zpl" \
     -H "X-Target-Dpmm: 12" > label-12dpmm.zpl

EPL2 output (application/epl)

With Accept: application/epl your label is converted to EPL2, the language used by Zebra's older printers. Text, barcode, box and line fields become EPL2 commands; sizes are computed from the printer's dot density (8dpmm = 203 dpi, 12dpmm = 300 dpi — EPL2 font metrics DIFFER between the two and the right table is selected automatically). Supported barcodes: ^BC Code 128, ^B3 Code 39, ^BE EAN-13, ^B8 EAN-8, ^BU UPC-A, ^B2 Interleaved 2/5, ^BK Codabar.

EPL2 has a narrower command set than ZPL, so not every label converts one-to-one. Nothing is dropped silently: whatever could not be translated is named in the X-Warnings header. Not converted today: QR (^BQ), DataMatrix (^BX), embedded graphics (^GF) and text blocks (^FB). Note also that EPL2 text sizing is not continuous — fixed font x integer multiplier — and the narrow bar width is limited per symbology (1-10 for Code 128, 2-4 for EAN/UPC); a value outside that range is clamped and reported too.

curl -X POST "https://api.labelixa.com/v1/printers/8dpmm/labels/4x6/" \
     --data-binary @label.zpl -H "Accept: application/epl" \
     -D headers.txt > label.epl

Outgoing webhooks

Instead of polling for the status of a bulk job we can notify you. Register an endpoint with POST /v1/webhooks; the events are toplu.tamamlandi and toplu.basarisiz.

curl -X POST "https://api.labelixa.com/v1/webhooks" \
     -H "X-API-Key: $LABELIXA_KEY" -H "Content-Type: application/json" \
     -d '{"url": "https://erp.example.com/labelixa"}'

The signing secret is returned in THIS response only and is never shown again in listings; if you lose it, delete the endpoint and create it again. The secret is separate from your account API key: rotating the key does not break webhook verification.

Every request carries Labelixa-Signature: t=<unix>,v1=<hmac>. The HMAC-SHA256 is computed over "<t>.<body>" — the timestamp is INSIDE the signature, so you can reject replays by checking how fresh it is. The format matches Stripe's, so code that already verifies Stripe webhooks can be adapted.

import hmac, hashlib, time

def verify(secret, body, header, tolerance=300):
    p = dict(x.split("=", 1) for x in header.split(","))
    t = int(p["t"])
    if abs(time.time() - t) > tolerance:
        return False
    expected = hmac.new(secret.encode(), f"{t}.".encode() + body,
                        hashlib.sha256).hexdigest()
    return hmac.compare_digest(p["v1"], expected)

Every request also carries Labelixa-Delivery-Id, and that id does NOT change across retries. If you see the same id twice, do not repeat the work — delivery is at-least-once.

Secret rotation

POST /v1/webhooks/{id}/rotate generates a new secret. The old one stays valid for a transition window (24 hours by default), and during that window every request carries TWO signatures (v1=… ,v1=…). Whichever one your verifier knows will match, so you can rotate without downtime. The remaining time is in the rotasyon_bitis field of the GET /v1/webhooks response.

Your verification code must support MULTIPLE v1 values — if you parse the header into a dictionary and read a single value you only see the last one, and you will reject valid signatures during the first half of a rotation.

Any response other than 2xx is a failure and is retried; redirects (3xx) are NOT followed. An endpoint that keeps failing is deactivated automatically — the listing then shows aktif: false and the last status code. The body contains NO row data: only the job id and counters, and you fetch the result with the job id.

Saved labels

Render endpoints are stateless and never store anything; saving happens only through these endpoints, on explicit request. Every account can save: Free 5, Starter 50, Professional 500, Business 2,500 saved labels; Enterprise unlimited. Anonymous (keyless) requests cannot save — a free account is enough, no card required. This limit is independent of the daily operation quota: one is how many labels you print, the other how many designs you keep.

Concurrency (If-Match)

Every read returns an ETag and every write requires the If-Match header: writing without it returns 428, writing with a stale version returns 412 (the body carries the current version). This prevents a second browser tab from silently overwriting the first one's changes. To overwrite deliberately, send If-Match: *.

Versions and trash

Each update snapshots the previous state (the last 50 versions per label are kept). Restoring an old version is written as a new version, so restoring is itself reversible. A deleted label stays in the trash for 30 days and can be restored; active labels are kept indefinitely. Idempotency-Key also applies to POST /v1/labels: retrying with the same key after a network timeout does not create a second label.

Printing

Render endpoints hand you an image; these endpoints send the job to a registered printer. A paid plan is required (Starter and above); the free plan includes a one-time trial of 25 labels on 1 printer. Billing does not double-count: pass the id of an already-rendered job as kaynak_is_id and the print is free; send raw ZPL and the label counts as produced here, and is billed here.

Job statuses — and why there is no `printed`

There is deliberately no “printed” status. Over raw 9100 you cannot prove a label was printed: the socket accepting your bytes only shows they reached the printer's buffer; running out of media, an open printhead or a jam all happen after the bytes are accepted, and the socket never tells you. The furthest state is dispatched = “we handed it over”. Every response also carries basim_onaylandi: false, so ignoring the field cannot be read as “then it printed”.

So: you can build a workflow that triggers printing, but do not build business rules on print confirmation. Where confirmation genuinely matters (pharma, track-and-trace), verification has to be read back from the label itself.

`failed` does not mean “nothing was printed”

A job can fail at five different points, and in four of them not a single byte reaches the printer (device not mapped, no adapter, identity check failed). In the fifth — the connection to the printer breaking — the bytes did go out, and on a multi-copy job part of it may already be on paper. The status response carries that difference in separate fields:

A job whose bytes reached the printer is never retried automatically — retrying it would print the label a second time. Such a job is held and the decision to continue is yours. Failures that never reached the printer keep being retried as before.

Preventing duplicates: Idempotency-Key

Resending a request after a network timeout is the right reflex — but the label may already be on paper. Send an Idempotency-Key header and a second request with the same key creates no new job: it replays the first response (Idempotency-Replayed: true). The same key with a DIFFERENT body returns 422 — recycling a key would silently print the wrong label. A 429 (queue full) does NOT consume the key; retrying with it is expected.

Printing from a stored template

Instead of yuk you can send sablon_id and degiskenler, and the payload is built from the template. Sending both is rejected. A missing or invalid variable returns 400 — a label printed with a missing variable wastes media, and only the person standing at the printer would notice.

Printing a saved label: etiket_id

Instead of yuk you can send the etiket_id of a label saved in your account (/v1/labels) together with degiskenler for its variables; the payload is built from the label. To print several labels as ONE job, send satirlar: one object per label, 1-1000 rows, where each row's values override degiskenler and etiket_sayisi becomes the row count. An empty satirlar list is rejected; omit it to print a single label. etiket_id cannot be combined with yuk, zpl or sablon_id (422). A missing or invalid variable returns 422 and names the row — the job is not queued, no row is skipped. Another account's label gets the same 404 as a missing one, and archived labels are not printed. Idempotency-Key, kopya, device_id / printer_group and billing work exactly as with a raw payload; the response carries etiket_id. With the approval workflow on, only published labels can be printed (422 otherwise); submit and approve the label in the panel under Saved work, or use POST /v1/labels/{id}/publish and /approve.

Printer groups: printer_group

Give a device a grup when you register it (DEPO, URETIM) and a print request may carry printer_group instead of device_id. The point is to keep device identifiers out of your business system: when a printer is replaced, the group moves with the device record and the ERP-side code is untouched. Resolution is DETERMINISTIC on purpose — we do not have the data a "pick the idle one" strategy would need, because a raw 9100 socket never reports load. One device in the group: that device. Several: the one marked default. No default, or more than one, and the job is NOT printed — the error names the devices that clash. Sending device_id and printer_group together is rejected. Group names are normalised to upper case and may contain only letters, digits, - and _. Nothing changes for integrations that do not use groups: grup starts empty and device_id works as before. Either way the response returns the device_id the job landed on.

Webhook notifications

You do not have to poll for status: subscribe to baski.teslim and baski.basarisiz. There is no baski.basildi event — the same reason there is no printed status. The body carries no raw label content: job id, stage and counters only. The failure event fires only once a job has failed permanently; notifying on every retry would bury the real failure in noise. A job that becomes uncertain fires baski.belirsiz — a separate event, so an automation that reprints on baski.basarisiz does not print it twice; existing subscriptions receive it only after you add it. Every baski.* body carries veri.sira (1, 2, … per job) and veri.status (the status at that event). Deliveries are retried, so an older event can arrive after a newer one: compare sira and ignore an event whose sira is lower than the last one you processed for that job.

The DirectPrint agent that collects these jobs and delivers them to the printer is downloaded here: /download

Setting up the agent (setup wizard)

On the computer the printers are connected to, run labelixa-agent setup (the one-line installer on the download page installs the agent and starts it for you). The agent opens the Labelixa page in the browser; check that it shows the same short code as the agent window and click Connect. Without a browser, create a pairing code on the Printers page of the panel and run labelixa-agent setup CODE. The free plan includes a trial with 1 computer, 1 printer and 25 labels in total (test labels don't count); beyond that a paid plan is needed. Downloading the agent is free.

The wizard looks at the computer's print queues: a single label printer is used without a question, several are offered as a list, an office printer only after you confirm it. Each chosen printer is added to your account and mapped on this computer, and a test label can be printed at the end. Nothing is sent to a printer during setup and the network is never scanned.

• labelixa-agent discover -mdns lists the network printers that announce themselves (Bonjour/mDNS) without sending anything to them.
• labelixa-agent import FILE adds many network printers at once from a CSV file with one name,address[,group] line per printer (-dry-run checks the file first). Every line is reported; one bad line does not stop the file.
• Running setup again on a connected computer keeps the connection and the printers already set up.

The agent asks the cloud for work and the cloud holds the request open until a job arrives (long polling), so a label is handed over as soon as it is submitted. The agent never opens a port: every connection goes from the computer to Labelixa.

Windows: silent install for IT teams

For Intune, Group Policy or SCCM roll-outs the Windows agent also ships as an MSI package. One line installs it as the LabelixaAgent Windows service, pairs it with a single-use code from the Printers page of the panel and imports the printer list: msiexec /i labelixa-agent_0.6.1_windows_amd64.msi /qn PAIRCODE=CODE PRINTERSFILE=C:\path\printers.csv. PRINTERSFILE is optional (one name,address[,group] line per printer); a failed pairing or import rolls the installation back and the code is not written to the installer log. The package and its checksum are on the release page.

USB printers: the operating system's print queue

A desktop printer on USB does not open port 9100; it shows up as a print queue in the operating system (the Windows spooler, CUPS on macOS and Linux). Agent 0.2.0 and later hands the bytes to that queue as RAW data: the driver renders nothing and the label language reaches the printer exactly as you sent it.

1. Register the device with adaptor: "os_driver" (POST /v1/devices).
2. On the agent machine, find the queue name: labelixa-agent discover -queues.
3. Map the device to the queue: labelixa-agent map-printer -device DEVICE_ID -queue "QUEUE_NAME".
4. Optionally run the agent in the background from every login: labelixa-agent install (a LaunchAgent on macOS, a systemd user unit on Linux; on Windows it prints the service commands to run in an administrator prompt).

On this path the furthest stage is submitted_to_os: the spooler accepted the job. That is one step short of submitted_to_printer — a printer that is switched off or out of media shows up in the operating system's queue, not here, and the queue reports no printer status (yazici_durumu: null). A job sent while the printer is off waits in that queue and prints once the printer is back on. A multi-copy job partly handed to the queue is not retried automatically.

The cloud record and the agent mapping must agree: an os_driver device mapped to a network address, or a raw_tcp device mapped to a queue, is not printed and fails with AdaptorYok — stopping beats printing on the wrong printer.

Printing ZPL to a USB Zebra printer from the cloud

PrintOps — metrics, alerts, print audit

The operations face of the print endpoints: what was printed, what is stuck, who printed it. Read-only — it summarises the account's existing print records and writes nothing. The same data is in the panel's PrintOps tab (same plan gate as printers). There is deliberately no 'printed' number: delivered means the bytes reached the agent, not the paper.

Business Central

Labelixa's Business Central extension (Labelixa Core + DirectPrint) uses these endpoints; your own integration can use them too. Authentication is an API key; an anonymous request cannot create a mapping (403). The plan gate is the same as for the print endpoints.

MCP server for AI assistants

Claude, ChatGPT and other MCP-capable AI clients can use Labelixa directly as a tool: the remote MCP server lives at https://api.labelixa.com/mcp (streamable HTTP, JSON-RPC; nothing to install — paste one URL into your client). No key is required — anonymous use is subject to free-tier limits; connect with Authorization: Bearer lbx_... to spend your own account quota.

MCP calls draw from the same quota and rate limits as REST — MCP is not a separate tier, it is the same API with a tool face. The table above shows highlights; the full, always-current tool list comes from the live server (tools/list) and the /mcp page.

Rule files for coding assistants

One rule file teaches Claude Code, Cursor, GitHub Copilot or Windsurf to validate and render label code with Labelixa instead of guessing from the text. Copy the file for your assistant from the Labelixa/agent-skills repository into your project: .claude/skills/labelixa/SKILL.md, .cursor/rules/labelixa.mdc, .github/instructions/labelixa.instructions.md, .windsurf/rules/labelixa.md. The rules call the MCP server or the CLI; the API key, if any, comes only from the environment.

Reading a printed label back

POST /v1/verify reads the barcodes in a photo or scan you upload — the answer to "I printed it, but will the handheld scanner read it?". Send the body as multipart/form-data with the image in the file field; PNG, JPEG, BMP and GIF are accepted, up to 5 MB and 6000×6000 pixels. The response carries olculdu (did the decoder run), an okunan list (each with format and veri) and a not field.

Do not confuse this with POST /v1/barcode-check: there the input is ZPL — we render the label and read back what we drew ourselves. Here the input is an image from the real world.

The limits of the result are printed in the response and should be taken seriously: "read" does NOT guarantee that every handheld scanner will read it, and "not read" does NOT prove the label is bad — the photo's angle, focus or lighting may simply be insufficient. This endpoint is NOT an ISO/IEC 15416 print-quality grade (A–F); that requires a verifier device.

curl -X POST "https://api.labelixa.com/v1/verify" \
     -F "file=@label-photo.jpg"

To do the same from your browser: Barcode Verifier.

Printer languages beyond ZPL

Labelixa renders and validates four printer languages. The endpoints below mirror the ZPL ones: render returns a PNG of the label, diagnostics returns diagnostics with line numbers. Coverage is deliberately an MVP subset per language and every response states its own limits — a command we do not draw is reported, never silently skipped.

POST /v1/language-detect answers a different question: given code you did not write, which language is it? The answer is heuristic and deterministic (no LLM), and confidence is reported as High/Medium/Low rather than a made-up percentage.

POST /v1/compatibility takes ZPL plus a printer model and returns a compatibility risk analysis — language posture, size-rule findings and preview scope. It is NOT an emulator and never returns a compatibility guarantee: we have physically tested only one of forty models, and a documented emulation mode is not native support.

Printer language conversion (SBPL / DPL / IPL → ZPL)

Three endpoints convert SATO SBPL, Honeywell (Datamax) DPL and Honeywell (Intermec) IPL streams to ZPL, so the label can be previewed, linted and printed with the ZPL tools. The body is the raw stream — real control characters and the manuals' readable notation (<STX>, <ESC>) give the same result. You choose the source language: automatic language detection does not recognise these three languages.

Parameters

Response

If there are warnings, the conversion is not 1:1. Commands outside the supported subset — printer settings (speed, darkness, sensor), RFID, job management and several 2D symbologies — are skipped WITH a warning, never silently. Show the warnings to whoever prints the label.

curl -X POST "https://api.labelixa.com/v1/convert/sbpl-to-zpl?dpmm=8" \
     --data-binary "<A><CS>6<V>100<H>200<L>0202<XM>ABCD<Q>1<Z>"

{"zpl": "^XA\n^FO199,99^A0N,48,48^FDABCD^FS\n^PQ1\n^XZ",
 "uyarilar": ["<CS> Print Speed not carried over to ZPL (manual p. 326; printer setting or outside the supported subset)"],
 "kaynak_dil": "sbpl", "birebir": false}

curl -X POST "https://api.labelixa.com/v1/convert/dpl-to-zpl?dpmm=8&etiket_boyu_mm=101.6" \
     --data-binary @label.dpl

Not verified on a physical printer. No SATO, Datamax or Intermec printer was used: the output is the ZPL equivalent according to each manufacturer's command reference. Positions of rotated fields are approximate and other font families are mapped to ^A0; both are reported as warnings. Check the preview and a test print before production.

Conversion does not count against the request quota; only the per-second rate limit applies. Body up to 512 KB (413 above), empty body 400. The endpoints are stateless: the code is neither stored nor logged.

To do the same in your browser: Printer Language Converter.

Embedding the preview in your own page

/embed/viewer is a minimal preview component with no site chrome; you embed it in your own application with an <iframe>. The ZPL travels in the URL fragment (#), not the query string — the fragment is never sent to the server, so your label content cannot land in our logs or any proxy's. The format is IDENTICAL to the preview tool's "copy link" output (base64 JSON), so you can paste that link straight in.

<iframe src="https://labelixa.com/embed/viewer#eyJ6IjoiXlhBLi4uIiwiZCI6IjgiLCJ3IjoiNCIsImgiOiI2In0"
        width="420" height="620" style="border:0"></iframe>

The height is the one you give; the component fits the image into the frame. The page is noindex and absent from the sitemap — it is a component, not a content page.

Postman collection

Every endpoint in this reference is a ready-made request in the public Postman workspace: postman.com/labelixa-3901521. The collection is generated from the OpenAPI schema (/openapi.json), not maintained by hand. The key travels in the apiKey variable and is NOT embedded in the collection — fork the workspace and set it in your own environment; leave it empty and requests run on the anonymous quota.

A badge for your README

If the ZPL files in your repository are linted in CI (POST /v1/diagnostics exits non-zero on errors), you can say so with a static badge — no counter, no tracking, cached for a day:

[![ZPL validated with Labelixa](https://labelixa.com/static/badge-zpl-validated.svg)](https://labelixa.com/tools/zpl-preview)

Use it only when the claim is true for your repository. Embedding the viewer in your own page, with a credit line under it: embedding guide.