Star CloudPRNT is a protocol, not a service. Star printers implement it, and it defines how a printer asks a server for work. That single distinction explains almost everything people find surprising about it.
The short answer: the printers are rarely what people want to replace. Star builds solid thermal hardware: the TSP and mC-Print ranges are among the most widely deployed counter printers in Europe, and their command language gives precise control over receipt layout. What teams want to stop doing is being the server. With CloudPRNT, the printer polls an HTTP endpoint you write, host and keep available. A push API removes that endpoint entirely.
Where the work actually sits
| Star CloudPRNT | Push REST API | |
|---|---|---|
| Who initiates | The printer polls your server | Your backend calls the API |
| Endpoint to build and host | Yes, by you | None |
| Latency floor | The polling interval | Sub-second |
| Queue, retries, exactly-once | Yours to implement | The service |
| Works behind restrictive networks | Yes, outbound only | Yes, outbound only |
| Fine control over the receipt | Yes | Yes |
Both models solve the genuinely hard problem: no inbound port on the shop's router. The difference is who carries the engineering.
The hardware is not the issue
It is worth separating the two questions, because they get conflated constantly.
Choosing a printer is a hardware question: paper handling, cutter reliability, connectivity, how it survives a busy counter. Star scores well on all of those, which is exactly why so many CloudPRNT deployments exist in the first place. If you already run Star printers, there is no good reason to rip them out.
Choosing how jobs reach that printer is a software question, and it is independent. A well-built printer behind a polling architecture you have to operate yourself is still a polling architecture you have to operate yourself.
If you are buying new hardware, we point people at specialist resellers rather than selling it ourselves: the printer market is better served by distributors who carry several ranges and handle RMA locally.
What hosting the endpoint really costs
The CloudPRNT specification is not difficult, and a first implementation takes an afternoon. The cost is not the first implementation; it is everything after it.
Availability becomes yours. Every printer in the fleet now depends on your endpoint being reachable. A deploy, an expired certificate, a misconfigured rate limiter: each one stops printing everywhere at once.
You build the queue. Jobs have to be stored, handed out exactly once, marked as delivered, and retried if a printer takes a job and then loses power mid-print. That is a small distributed-systems problem, and it is easy to get wrong in ways that only appear under load.
Polling sets your latency floor. A three-second interval means an average of a second and a half before the kitchen even sees the ticket. Shortening the interval multiplies request volume across the fleet.
Load scales with printers, not with printing. A hundred printers polling every few seconds is a constant, permanent request load on your infrastructure, whether or not anything is being printed.
None of this is a criticism of the protocol. CloudPRNT is a reasonable design that deliberately puts you in control. The question is only whether you want that control enough to operate it.
When to keep CloudPRNT exactly as it is
Two situations, both legitimate:
- You already have the endpoint running and it works. A polling server you built two years ago, that has been stable and that someone understands, is not a problem to solve. Migrations have a cost too.
- The printer must only talk to infrastructure you control, for policy or compliance reasons. Owning the endpoint is then a requirement, not an overhead.
If neither applies, hosting a polling server is work you are choosing rather than work you need.
What a push API changes
curl -X POST https://www.expedy.fr/api/v2/printers/{printer_uid}/print \
-H "Authorization: API_SID:API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"printer_msg": "ORDER #1043\n2x Margherita", "origin": "pos"}'
No endpoint to write, no queue to operate, no polling interval to tune, and no server of yours in the path when a ticket has to come out. A Star printer with a USB port can be driven this way today through a Raspberry Pi adapter, which keeps the hardware you already bought and moves only the server side.
What a printer manufacturer cannot do for you
Every vendor implements its own protocol for its own range: CloudPRNT for Star, Server Direct Print for Epson, and so on. That is normal and, from their side, entirely reasonable: they sell printers, not integration layers.
The consequence is structural rather than a fault. A manufacturer's protocol can only ever cover that manufacturer's printers, so the moment your estate holds two brands you are maintaining two integrations, two sets of credentials and two sets of failure modes. And no printer maker ships a Shopify app or a WooCommerce plugin: that is not their business.
This is the layer a print platform exists for: one endpoint whatever the brand, plus the connectors: Shopify, WooCommerce, PrestaShop, HubRise, Zapier: that sit between an order and a printed ticket. Where a manufacturer exposes an open transport such as MQTT, that hardware can be brought under the same endpoint instead of becoming a second integration to maintain.
Migrating without a flag day
- Keep the CloudPRNT endpoint running and add the push call alongside it.
- Move one site to the new path and compare tickets for a week.
- Roll forward site by site; the endpoint stays as your rollback.
- Decommission the endpoint only when the last printer has moved.
The free plan covers steps one and two before you commit to anything. And if the answer at the end is "our endpoint is fine, we will keep it": that is a legitimate outcome of the exercise.
FAQ
Is Star CloudPRNT a service or a protocol?
A protocol implemented by Star printers. There is no hosted service behind it: you write and host the endpoint the printer polls, which means you own its availability and its queue.
Do I have to replace my Star printers?
No, and usually you should not. Star builds reliable counter hardware, and the printers are independent of how jobs reach them. A Star printer with a USB port can be driven through a Raspberry Pi adapter while the server side moves to a push API.
How much latency does polling add?
On average half the polling interval. A three-second interval means about 1.5 seconds before the printer even asks for the job. Shortening it increases request volume across the whole fleet.
When should I keep my CloudPRNT endpoint?
When it already runs, is stable and someone understands it: a migration has a cost too. Also when policy or compliance requires the printer to talk only to infrastructure you control.
Can I migrate gradually?
Yes. Keep the CloudPRNT endpoint running, add the push call in parallel, move one site at a time, and decommission the endpoint only once the last printer has moved.
Why use a print platform instead of the manufacturer's own protocol?
Because a manufacturer's protocol only covers that manufacturer's printers, and no printer maker ships a Shopify app or a WooCommerce plugin. A print platform gives you one endpoint whatever the brand, plus the connectors between an order and a printed ticket.