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 caretlyGo
go get github.com/jaapieaapie1/zpl/clients/goPython
pip install caretlyNode.js
npm install @caretly/caretlyPHP
composer require caretly/caretlyC# / .NET
dotnet add package CaretlyJava
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_KEYenvironment variable. The clients send it asAuthorization: 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
rendersends one ZPL document as the raw request body. It can hold several^XA…^XZlabels, and each becomes a page.renderFilessends several files asmultipart/form-data. Each file starts from a fresh printer state, and pages follow the order of the files. See Render many labels.
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
429and503responses and connection errors, 2 times by default. Set the maximum retries to0to turn retries off. - They wait the number of seconds in
Retry-Afterwhen 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.