Skip to main content
The official client libraries wrap the POST /render endpoint. They send your ZPL, retry rate-limited and overloaded requests without billing you twice, and give you the file together with the page count and labels billed.

Choose your language

Rust

cargo add caretly

Go

go get github.com/jaapieaapie1/zpl/clients/go

Python

pip install caretly

Node.js

npm install @caretly/caretly

PHP

composer require caretly/caretly

C# / .NET

dotnet add package Caretly

Java

dev.caretly:caretly:0.1.0
The source of every client lives in clients/ on GitHub.

Render a label

Every client renders a ZPL string to a PDF by default and saves it to a file:

Shared behaviour

All seven clients work the same way. Only the naming follows each language’s conventions.

API key and base URL

  • Pass the API key to the constructor, or set the CARETLY_API_KEY environment variable. The clients send it as Authorization: Bearer <key>. See Authentication for test and live keys.
  • The key is optional. A self-hosted server that runs without keys doesn’t need one.
  • The base URL defaults to https://caretly.dev. Change it to point a client at a self-hosted server.

Render one document or several files

  • render sends one ZPL document as the raw request body. It can hold several ^XA…^XZ labels, and each becomes a page.
  • renderFiles sends several files as multipart/form-data. Each file starts from a fresh printer state, and pages follow the order of the files. See Render many labels.
Most clients also have renderPdf and renderPng shorthands, and a health call for GET /health.

Render options

The clients leave unset options out of the request, so the server defaults apply. They check page, dpmm and the idempotency key before sending, and fail without making a request when a value is invalid.

Result

A successful render returns the file and the metadata from the response headers:

Errors

Each error status has its own error type, so you can handle an invalid label differently from an expired key: Every API error carries the status code, the server’s plain-text message and the Retry-After delay. Other statuses, such as 500, raise a generic API error. Network failures and timeouts have their own types.

Retries and idempotency

  • The clients retry 429 and 503 responses and connection errors, 2 times by default. Set the maximum retries to 0 to turn retries off.
  • They wait the number of seconds in Retry-After when the server sends it. Otherwise they back off 0.5 s, 1 s, 2 s, 4 s, up to 8 s.
  • When retries are on and you don’t set an idempotency key, the client generates a UUID per call and sends it on every attempt. A retried request is never billed twice.
  • Timeouts aren’t retried. The server may still be rendering the request, so the client raises a timeout error on the first one. Pass your own idempotency key, such as an order number, to retry it safely yourself.
  • Other error statuses aren’t retried.
See Safe retries with Idempotency-Key and Rate limits.