A REST API for your kitchen printer
Your order system sends one HTTPS request, and the ticket prints on a USB ESC/POS printer at the pass. The Printercow dongle sits on the printer, so there is no computer, driver or print server in the kitchen.
The PC next to the printer is the part that breaks.
A USB kitchen printer usually needs a computer with a driver beside it, plus software on that computer that forwards orders. Updates, sleep mode and a full disk all stop the tickets. With Printercow, the printer gets an HTTPS endpoint instead.
How it works.
- 01
Teach it once
Connect Claude or another MCP client, let it print a test ticket and propose a recipe with a print action. You approve the recipe on the dongle page.
- 02
Call the action
Your order system sends POST /api/v1/devices/{dongleId}/actions/print with an API token from the Connect page and the ticket as JSON.
- 03
Read the result
The response lists each USB step and check.outcome: passed, failed or unverifiable. HTTP 200 alone does not mean the ticket printed.
- 04
Add more printers
Every dongle in your workspace with the same printer model (same USB ID) runs the same recipe. No AI is involved after the first one.
One request per ticket.
The parameters come from the approved recipe and are checked before anything is sent to the printer; a wrong type returns 400. The recipe for the simulated printer takes text. The Idempotency-Key, here the order number, keeps a retry from printing the ticket twice.
The API reference lists every call, its fields and its answers.
1 curl -X POST "https://milk.printercow.com/api/v1/devices/$DONGLE_ID/actions/print" \ 2 -H "Authorization: Bearer $PRINTERCOW_TOKEN" \ 3 -H "Content-Type: application/json" \ 4 -H "Idempotency-Key: order-1042" \ 5 -d '{ "text": "ORDER #1042 TABLE 7\n1 x FLAT WHITE\n2 x CROISSANT" }'
What it needs, and its limits.
- ESC/POS printers over USB. Runs on a real 80 mm receipt printer as well as end to end against a simulated one.
- Every ticket goes through the Printercow cloud. If the dongle is offline, this call returns 409 at once; sent as a print job (POST /api/v1/print-jobs) the ticket waits instead, 10 minutes by default, and prints when the dongle is back.
- The first recipe needs one session with an AI client. After that, no AI is involved.
- Proof that paper came out needs a paper sensor in one of the dongle's two sensor slots; without one, the check reads the printer's status reply.
Questions.
What happens when the kitchen printer or dongle is offline?
The direct print call returns HTTP 409 with the error "offline" at once. Sent as a print job to POST /api/v1/print-jobs, the ticket waits in the dongle's queue instead, 10 minutes by default or as long as you set, and prints when the dongle is back; a webhook says whether it printed or expired. Printercow can also send a webhook when a dongle goes offline or comes back, so your system can alert staff.
Does every kitchen ticket go through an AI?
No. An AI is only needed once, to work out the printer's commands and propose the recipe. After you approve it, each ticket is a plain REST call that runs the saved USB steps.
How do I know a ticket actually printed?
Each call returns a check result: passed, failed or unverifiable. By default the check reads the printer's status reply. With a paper sensor in a sensor slot, the check confirms that paper left the printer. Neither proves what text is on the ticket.