For developers & ISVs

Integrate restaurant hardware once.

Every POS team ends up owning a private zoo of printer drivers, certified-hardware whitelists, and 'printer offline' tickets. A ProxyNode moves that whole problem behind one HTTP API on the restaurant's LAN — and gives you a simulator so the integration runs in CI before hardware exists. The project is prototype-stage: bench-validated end to end on real hardware, pilots starting, and source-open at launch.

Start with the simulator Get early access

The API

One call. The node does the last mile.

Nodes announce themselves over mDNS and serve JSON on the LAN. Your software never touches ESC/POS, RS-232 framing, or USB descriptors — unless it wants to.

Print a receipt

curl http://proxynode-7f3a.local/print \
  -X POST -H "content-type: application/json" \
  -d '{
    "lines": [
      { "type": "text", "value": "Table 4", "bold": true },
      { "type": "barcode", "symbology": "qr", "value": "ORDER-1042" },
      { "type": "cut" }
    ]
  }'

Ask how the hardware actually is

curl http://proxynode-7f3a.local/status

{
  "identity": { "deviceId": "pn-7f3a", "variant": "wifi" },
  "online": true,
  "uptimeSeconds": 86213,
  "printers": [{
    "type": "printer_status", "endpoint": "receipt",
    "online": true, "paperOut": false, "coverOpen": false,
    "drawerOpen": false
  }]
}

Live paper, cover, and drawer state, read over DLE EOT. And when a reading can't be taken — a write-only printer, a dead status line — the driver layer models it as known: falserather than inventing "no faults", so "paper is fine" and "I can't tell" never get conflated.

Already speak :9100?

If your software prints raw ESC/POS to network printers today, there is no integration at all: point it at the node's :9100 port. DLE EOT status queries are answered too.

Swap hardware, not code

Star to Epson to a $60 generic is a node-side config change. Your software keeps calling the same API.

Tune per printer, remotely

Cut clearance, print width, USB pacing — runtime config over PUT /config, persisted on the node. No reflash, no site visit.

CI-first

Your integration passes before a printer exists.

The digital twin is a LAN service that mirrors the firmware byte for byte — same API, same :9100 behavior, same telemetry — with fault injection for the failure paths you can't schedule on real hardware.

$ pnpm sim                 # digital twin: HTTP :8080, :9100, mDNS
$ pnpm print               # POST a sample receipt — renders in the console
$ pnpm conformance         # protocol conformance suite vs the twin

sim> paper out             # now make it a bad day
sim> cover open
sim> offline

The conformance suite is the honest answer to "does passing against a simulator mean anything?" — one suite, validated against shared schemas, that runs identically against the twin and a physical node on your bench.

Protocol conformance is unconditional; physical-effect assertions skip with a printed reason when the hardware isn't attached — never a silent pass.

The reference material we wished existed.

Deep technical guides on the protocols and failure modes of receipt printing — useful whether or not you ever run a node.

All guides →