PrintNode alternative: when a client app on a computer is the problem

PrintNode does what it says: you POST a job to its API and a printer prints it. The integration is clean and the documentation is good. If you are searching for an alternative, it is almost never because the API disappointed you: it is because of one architectural decision.

The short answer: PrintNode reaches your printer through a client application that must be installed and running on a computer or Raspberry Pi on the same network as the printer. That machine is now part of your production system. If you cannot guarantee a powered-on, updated, unattended computer at every site, you need an architecture where the printer connects on its own.

The structural difference

	PrintNode	Expedy Print
What reaches the printer	A client app on a local computer	The printer's own outbound connection
Machine required on site	Yes, one per location	No
OS to keep updated	Windows, macOS or Linux	None
Works with existing USB printers	Yes, via the client	Yes, via a Raspberry Pi adapter
Works with no computer at all	No	Yes, with a 4G/Wi-Fi/LAN cloud printer
Billing unit	Per computer running the client	Per printer

Both are push APIs, both queue jobs, both are legitimate. The question is only whether a computer at each site is acceptable in your deployment.

When the client app is fine

Be honest about this before switching. The PrintNode model is a good fit when:

• Each site already has an always-on POS terminal or back-office PC that someone maintains.
• Your printers are existing USB devices you have no intention of replacing.
• You have few sites, and they are staffed by people who can restart something when asked.

In that situation, adding a cloud printer buys you very little.

When it becomes a liability

The trouble starts at scale and at distance:

Someone turns the computer off. A laptop that closes at 6pm, a PC on a switched power strip, a Windows update that reboots into a login screen and waits. Every one of these silently stops printing, and the failure surfaces as a missing order rather than an alert.

One more thing to maintain per site. Ten sites means ten operating systems, ten antivirus policies, ten sets of credentials, ten machines that eventually need replacing. The print integration is fine; the fleet of computers is the cost.

Sites you do not control. If you are a SaaS vendor or an agency whose customers own the premises, "install our print client on a computer and keep it running" is a support burden you will carry forever. This is the single most common reason developers migrate.

Per-computer billing. When the unit of billing is the machine running the client, consolidating printers per site becomes a cost optimisation exercise rather than an operational one.

What replaces it

A cloud printer holds its own outbound connection to the print service, so there is nothing local to install:

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": "TEST\nLine 2", "origin": "migration-test"}'

If you want to keep the USB printers you already own, a Raspberry Pi USB adapter plays the role PrintNode's client plays, but it is a dedicated appliance rather than a general-purpose computer, with no desktop OS to patch and no user to log in.

Migrating an existing integration

The API shapes are close enough that this is usually a half-day:

1. Map the identifiers. PrintNode printer ids become printer_uid values in your config.
2. Convert the payload. If you were sending raw ESC/POS base64, you can keep doing so; if you were sending PDFs, see PDF printing.
3. Move the credentials. One API key pair replaces the PrintNode key.
4. Run both in parallel. Print to both services for a few days with the old one as the source of truth, and compare.
5. Decommission the client machines last. They are your rollback.

Which to choose

Choose PrintNode if every site has a computer you control and you would rather not touch the hardware. Choose a self-connecting printer if the computer is the part you cannot rely on: because it is in someone else's building, because there are fifty of them, or because it is the component that keeps failing at 8pm on a Friday.

There is a free plan to test the second option against your own workload before committing.

FAQ

What is the main difference between PrintNode and Expedy Print?

PrintNode reaches printers through a client application running on a computer at each site. Expedy printers hold their own outbound connection, so nothing has to be installed or kept running locally.

Can I keep my existing USB printers if I move away from PrintNode?

Yes. A Raspberry Pi USB adapter makes an existing USB printer addressable over REST. It replaces the client machine with a dedicated appliance that has no desktop OS to maintain.

How hard is it to migrate an existing PrintNode integration?

Usually half a day. Both are push APIs, so the work is mapping printer ids to printer_uid values, swapping credentials, and running both services in parallel until you trust the new one.

Is PrintNode ever the better choice?

Yes, when every site already has a maintained, always-on computer and you do not want to change any hardware. The client model is only a liability when that computer cannot be relied on.