A print job is sent to a device record: the
device_id you get when you register the printer
(POST /v1/devices; GET /v1/devices lists them). The
network address lives in the agent's mapping on the computer next to the
printer, not in your integration, so moving the printer means changing one
mapping — not your ERP code.
Pin the printer's identity
When you map a network ZPL printer, pin its identity in the same step:
The agent asks the printer who it is (ZPL ~HI), stores a digest
of the answer and replies Identity pinned. From then on it asks
the same question before every job — not once at install
time, because install time is not when a DHCP lease moves.
On a mismatch, nothing is printed
If the device that answers at the mapped address gives a different answer,
the agent does not send the label. Its log says so in one line:
identity mismatch: the device at 192.168.1.50:9100 is NOT the device pinned for "DEVICE_ID". Nothing was printed.
followed by the command to pin again if the printer was really replaced.
The job is marked failed with the error type KimlikUyusmazligi
and is not retried automatically. That matters: if the job
waited in the queue, fixing the pin would print the old label on whatever
device now holds the address — so sending it again is your decision.
What we measured
On 2 November 2026 we ran this on a Zebra GK420d on the network, with agent
0.6.1 and the production service:
pinning answered Identity pinned and a test label printed;
we then changed the stored digest so that the printer's answer no
longer matched — the same situation as a different device answering — and
sent two jobs: no paper came out, the log showed the
mismatch line above and both jobs were marked failed with
KimlikUyusmazligi;
we restored the original digest and watched for 60 seconds: the failed
jobs did not print on their own; a new test label printed
normally.
We simulated the mismatch on one printer by changing the pin; we did not
swap two physical printers at the same address.
Where the protection stops
Network ZPL printers only. The question is
~HI, the one identity query we have verified. For EPL, TSPL and
CPCL there is no verified query, so pinning is unavailable and the agent says
so. A USB printer is reached through the operating system's print queue,
which carries data one way only, so the agent cannot ask it anything.
It is opt-in. A device that has not been pinned is not
checked.
Identical twins look the same. The pin is the
printer's own answer to ~HI: model, firmware version,
resolution and memory. Our GK420d answers
GK420d-200dpi,V61.17.17Z,8,2104KB — there is no serial number in
it. Two printers of the same model with the same firmware and memory give the
same answer, so the check cannot tell them apart. It stops a different model
or configuration answering at the address; for identical printers, reserved
addresses remain your protection.
A firmware update can change the answer. Then the job
stops and the message asks you to pin again. A stopped line beats a label in
the wrong box.
Verified is not printed. A passed check means the right
device received the bytes. Paper out, an open head or a jam happen after
that, and raw printing does not report them.
When you see a mismatch
Find out which device now holds the address: print its configuration
label or check the DHCP lease table, as in
the diagnosis guide.
Point the mapping back at the right printer, ideally at a reserved
address.
Pin again only if the printer itself was replaced or its firmware was
updated.
What happens when a different printer answers at the address?
If the printer was pinned and the answer to the identity query differs from the pinned one, the agent sends nothing. Its log says the device is not the one pinned and that nothing was printed, and the job is marked failed with KimlikUyusmazligi. It is not retried automatically.
Does the check work for every printer?
No. It works for ZPL printers reached over the network, where the agent can ask ~HI. EPL, TSPL and CPCL have no verified identity query, a USB print queue carries data one way only, and a device that was not pinned is not checked.
Can it tell two identical printers apart?
No. The pin is the printer's answer to ~HI — model, firmware, resolution and memory, no serial number. Two printers of the same model with the same firmware and memory answer the same, so reserved addresses remain the protection between them.
