ESC/POS printing from an API

Receipt printers do not take PDFs. They take a stream of ESC/POS bytes. PrintSocket carries that stream to the printer unchanged, from an HTTP call on your server.

Send the bytes as raw content

A job's content.format is either pdf or raw. raw means "these bytes are for the printer, not for a driver to interpret", which is exactly what an ESC/POS command stream is. Send it base64-encoded inline, or as a URL we fetch: 

curl https://api.printsocket.com/v1/jobs \
  -H "Authorization: Bearer sk_test_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: receipt-88213" \
  -d '{
    "printer_id": "prn_8f2k1",
    "title": "Receipt #88213",
    "content": { "format": "raw", "base64": "G0AbYQEuLi4=" }
  }'

The response is a job object with an id and a status, the same as any other job. Watch it with GET /v1/jobs/{id}/events or subscribe to webhooks.

Raw content is passed through unvalidated

This is worth being explicit about, because it cuts both ways. We do not parse your ESC/POS, do not rewrite it, and do not check it. Whatever you send is what reaches the printer. That means every command your particular model supports is available to you on day one, including the vendor extensions no abstraction layer would have covered.

It also means a malformed stream prints garbage rather than returning an error. The job will report succeeded, because from our side it was delivered and printed. Test against real hardware, or against a virtual printer first.

Copies, on a raw job

copies is a single top-level field, and PrintSocket hands it to the platform's own copy mechanism where there is one. For raw content there is no such mechanism, so the payload is repeated. One job in, one job in the print queue, either way.

If your stream ends with a cut command, that is what you want: three copies means three receipts, each cut. If it does not, you get one long receipt.

What this does not do

  • It does not generate ESC/POS for you. There is no "print this text at this size" helper here. You build the byte stream, with a library in your own language or by hand.
  • It does not handle code pages, fonts or character encoding. Those are commands in your stream, and printers differ.
  • It does not know your paper width. 58 mm and 80 mm printers take different byte counts per line, and that is a property of the stream you send.
  • Print options like duplex, color and paper are meaningless on a raw job. Send them and they are ignored or warned about, not applied.

In short: PrintSocket is the transport, not the formatter. If you want a hosted receipt designer, this is the wrong layer.

Getting to a printer

A receipt printer is reached the same way as any other: install the agent on the machine the printer is attached to, enroll it once, and it reports every queue it can see. The agent connects outbound, so nothing on the till network needs to be reachable from the internet. See print from a web app for how that model works, and devices and printers for the enrollment call.

Start free Job reference