Printing, as an API call.
Everything a print integration normally costs you — paper sizes, margins, ESC/POS byte streams, cutting, retries — happens on our side. You send a template name and the values that go in it.
The model
Printers have names
Not ports, not serial numbers, not IP addresses. You address "Front counter". If that unit dies, its replacement takes the name and your code never notices.
Templates hold the layout
Designed in the browser, stored server-side, versioned by name. Your payload is a flat object of values, plus arrays for repeating rows like receipt lines.
Jobs are queued, not awaited
A job comes back with an id and a status. The printer may be off; your checkout shouldn't block on it. Add ?wait=true when you do want the outcome.
Keys carry the tenant
The key decides which organisation a request belongs to — never something in the payload. Test keys render and queue without printing.
Start in five minutes
Make a key in the dashboard under Keys. Use a lbl_test_ key while you build: it renders and queues, but no paper moves.
Then ask what exists, and print to it.
curl https://instntprint.com/v1/printers \
-H "Authorization: Bearer $KEY"
curl -X POST https://instntprint.com/v1/jobs \
-H "Authorization: Bearer $KEY" \
-H "Idempotency-Key: order-2026-1042" \
-H "Content-Type: application/json" \
-d '{
"printer": "Front counter",
"template": "Kassabon",
"data": { "bonnummer": "1042", "totaal": "17,45" }
}'What people build with it
Point of sale
Receipts with line items, VAT lines and a cash drawer pulse. Idempotency keys keep a double tap from printing twice.
Webshops and fulfilment
Packing slips at the bench, address labels on the LabelWriter, a whole CSV of orders in one batch call.
Kitchens and counters
One order, several printers: food to the kitchen, drinks to the bar, a pickup slip up front. Each with its own idempotency key.
Back office and archives
Sequential numbering, QR codes that resolve back into your own system, and labels that outlive the software that made them.
A working integration to read
On the pages for each trade a printer draws what your call produces, live, without an account. Sign in and you get the example shop with it: a till, an order screen and an archive that print through this same API — no framework, no build step, the whole integration one file of about two hundred lines.
The edges, up front
Two printers per bridge, one at a time
USB hubs behind the bridge are unreliable in practice. One printer per bridge is the setup we stand behind today.
Receipt design is desk work
Receipts are built from blocks in the browser. The iOS app can use them and fill them, but not design them.
Webhooks are not there yet
Job status is polled today. Outbound webhooks, inbound hooks with field mapping, a Make module and Home Assistant are next.
Head widths of rare models
Well-known DYMO and Epson models are measured. An unknown model falls back to a sensible default and says so, instead of quietly printing at the wrong width.
Run it yourself
The server is a single Python process with SQLite behind it. Point a bridge at your own host and nothing leaves your network. Useful when a customer's policy says printing data can't go to a third party.