Comparison
PrintNode invented this category and it works. Here is what we do differently, and — just as importantly — the cases where it is still the better choice.
The shared model
A local agent next to the printer, an outbound connection, an API that names a printer rather than a network address. We are not claiming a novel architecture — we are claiming a better implementation of a proven one.
Not architecture. It comes down to what happens on a bad day: what a retry does, what a failure tells you, and whether you can find out what happened to one specific label without asking a warehouse.
That is where we spent our effort, and it is what the rest of this page is about.
Where we differ
Send an Idempotency-Key and a retried request returns the original job rather than printing a second label. The agent keeps its own ledger too, so a redelivered job after a crash or reconnect replays its outcome instead of reprinting.
Duplicate labels are the most expensive failure in fulfillment. We did not want that to be something every customer re-implements in their worker.
Seven states, each defined precisely, including a written statement of what completed does not mean. We will not tell you paper physically emerged, because no print API can know that.
You get the real failure reason on the job, not a generic error. See the state model →
Our compatibility matrix marks Windows raw printing as unsupported and says why. Our security page separates what ships today from what is on the roadmap. You should be able to disqualify us from a web page in ten minutes rather than in week three of an integration.
One plan, metered per completed job. No seats, no printer limits, no feature gates — offline queueing and idempotency are not an upgrade. Failed jobs are never billed. See pricing →
Feature comparison
RocketPrint's column reflects what is verified in our own system. For PrintNode, check their documentation directly — we are not going to characterize a competitor's product from memory.
| Capability | RocketPrint | Notes |
|---|---|---|
| Outbound-only local agent | Yes | Both products work this way. No inbound rules either way. |
| Raw ZPL / EPL / ESC-POS pass-through | Yes | Verified byte-for-byte on a printer's TCP port. |
| PDF and plain-text printing | Yes | Through the station's own print system. |
| Offline queueing with auto-dispatch | Yes | Jobs persist as pending and dispatch in order on reconnect. |
| Idempotency keys on job creation | Yes | Server-side, plus an agent-side ledger that survives restarts. |
| Published definition of every job state | Yes | Including what completed does not cover. |
| Per-key rate limits with Retry-After | Yes | 300 requests/minute, burst 30. |
| Webhooks for job status | Not yet | Polling today. PrintNode has this and we do not. |
| Raw printing on Windows | Not yet | Returns an explicit error. PrintNode supports Windows raw printing. |
| Code-signed installers | In progress | Signing identities being obtained. PrintNode ships signed clients. |
| Years in production | New | PrintNode has a decade of operational history. We do not. |
Be honest
If any of these describes you, use them. A comparison page that cannot name a losing case is marketing, not information.
Raw pass-through on Windows is unfinished here. This is the most common reason to stay put, and it is a good one.
If your architecture cannot poll for job status, we are not ready for you yet.
Some IT departments will not deploy an unsigned binary, and that is a reasonable policy. Ours are unsigned until the certificates land.
If procurement requires years of uptime history and formal agreements in place, an established vendor is the lower-risk answer right now.
Questions
Probably not on its own. Switch when something specific is costing you — you want idempotent retries you do not have to build, you want failures that explain themselves, or you want a vendor small enough to answer an engineering question directly. 'Working fine' is a good reason to stay put.
The shape is the same: install an agent next to the printer, send a job naming a printer ID. The work is swapping the client call and re-mapping your stored printer IDs, then running both in parallel for a week.
Partially, and we would rather say so here. A Windows station registers printers and prints documents, but raw pass-through printing is not finished. If your labels come off Windows machines, PrintNode is the right answer today.
PrintNode has them and we do not yet. Job status is polled today. If push notification is a hard requirement for your architecture right now, that is a real reason to wait for us or stay put.
Try both
Install the agent on one bench and send it the same labels for a week. Nothing about that is disruptive, and it answers the question better than any table.