Your backend
One authenticated POST per job. No SDK is required — it is a JSON REST API — but a Node client is available if you want typed helpers and a status poller.
Product
Your application makes one consistent request. RocketPrint resolves the organization, the printer, and the station that owns it, then dispatches the job over a connection that station opened outward.
Architecture
There is no appliance to buy and no inbound connection to allow. The agent is an ordinary desktop application that runs next to printers you already own.
One authenticated POST per job. No SDK is required — it is a JSON REST API — but a Node client is available if you want typed helpers and a status poller.
Validates the request, persists the job, and finds the station that owns the target printer. If that station is connected, the job dispatches immediately. If it is not, the job waits and dispatches on reconnect.
A small desktop application that signs in to your organization, reports every printer the operating system can see, and holds one authenticated outbound connection open. It receives jobs, prints them, and reports back what happened.
Thermal label and receipt printers get their native language byte-for-byte. Documents go through the station's own print system with whatever driver that machine already has installed.
The request
The same endpoint prints a Zebra label, a packing slip, and a kitchen ticket. What changes is contentType.
$ curl -X POST https://rocketprint.io/api/v1/print-jobs \
-H "X-API-Key: $ROCKETPRINT_KEY" \
-H "Idempotency-Key: order-1042-label" \
-H "Content-Type: application/json" \
-d '{
"printerId": "6a4738f7462183c7f5d70598",
"title": "Order #1042 label",
"contentType": "raw_base64",
"content": "XlhBLi4uXlha",
"source": "my-shop",
"options": { "copies": 1 }
}'
{
"id": "job_abc123",
"printerId": "6a4738f7462183c7f5d70598",
"stationId": "stn_bldr_wh_01",
"status": "sent",
"createdAt": "2026-08-22T14:03:07Z"
}raw_base64 carries the printer's own language — ZPL, EPL, or ESC/POS — base64-encoded. It is written to the queue untouched.
pdf_base64 and text print through the operating system on the station. Use these for packing slips, invoices, and pick lists.
URI-based content types exist in the API but are disabled by default and return a validation error unless an operator explicitly enables station-side fetching. Send base64.
The job lifecycle
The most valuable thing a print API can give you is an honest answer about what happened. Here are the states, defined precisely.
Capabilities
Not feature bullets — the six behaviors that decide whether a print integration survives a real operation.
Your application submits one consistent API request naming a printer. RocketPrint resolves the organization, the printer, and the station that owns it, and dispatches over a connection that station opened outward. Your local network is never addressed from the internet, and your application never learns a hostname, an IP, or a port.
Raw ZPL, EPL, and ESC/POS pass through byte-for-byte to the print queue. Nothing is rasterized, re-scaled, or re-encoded, so a barcode you designed at 203 dpi prints at 203 dpi. We have verified the exact bytes arriving on a printer's TCP port.
A station that is asleep, rebooting, or briefly off the network does not turn into a failed order. Jobs for an offline printer persist as pending and dispatch automatically, in creation order, the moment the agent reconnects.
Every job has an id, a status, timestamps for creation, dispatch, and completion, and a failure reason when it fails. Filter by status, printer, or source. Support can answer "what happened to that label" by looking, not by asking someone to try again.
Send an Idempotency-Key and a retried request returns the original job with Idempotency-Replayed: true rather than printing a second copy. The same input replays; different input under the same key is rejected with a conflict.
Stations, printers, live presence, job history, API keys with one-time reveal, and monthly usage — across every location, in one console. Printing fails in physical ways; this is where your team sees it happen.
The console
Live station and printer presence, job history with failure detail, API key management, and monthly usage.
Boundaries
Every one of these is a real limit today. If one of them is a blocker for you, we would rather you find out on this page than three weeks into an integration.
completed means the print command succeeded, not that a sensor saw paper. No print API can honestly claim otherwise.
Job status is polled. Webhooks are on the roadmap; until they ship, use GET /v1/print-jobs/:id or the Node SDK's poller.
A Windows station registers printers and prints documents, but raw pass-through returns an explicit error instead of printing something wrong.
RocketPrint is transport and status. Generating ZPL or a PDF is your application's job — or your carrier's.
Five minutes, honestly
Install the agent, create a key, POST a label. The quickstart is two curl commands.