ZKTeco attendance integration
ZKTeco terminals speaking the ADMS push protocol deliver punches to SignHR as they happen. Read the field-validation note below before you plan a rollout.
SignHR implements the ZKTeco ADMS push protocol, so terminals deliver punches directly with no PC software in between. The device is identified by its serial number, which is how SignHR knows whose workspace a punch belongs to. One caveat we would rather you read here than discover later: the adapter is built and tested against the protocol, but has not yet been validated against physical ZKTeco hardware. Treat the first terminal as a pilot.
How it works
- 1
The device finds SignHR by serial number
ZKTeco terminals post to a fixed path they control, so they cannot carry a workspace segment or a token. SignHR resolves which tenant a device belongs to from the serial number it sends, which is registered against your workspace in advance.
- 2
A handshake sets the terminal's behaviour
On boot the device asks for its operating parameters. SignHR answers with real-time delivery enabled, so punches arrive as they happen rather than on a polling schedule.
- 3
Offline backlogs are asked for, not skipped
The handshake tells the terminal that SignHR wants everything it still holds, rather than only what happened since now. That distinction matters after an outage: the wrong answer here silently suppresses a device's entire offline backlog on every reconnect.
- 4
Punches become attendance
Records are deduplicated, localised, paired into sessions and attributed to the correct business date, the same as every other punch source.
Where it stops
Every integration has edges. These are ours, stated here rather than discovered during implementation.
- Not yet validated against physical hardware. The adapter is written to the ADMS protocol and covered by tests, but no ZKTeco terminal was available while building it. The first real device should be piloted, not rolled out across sites.
- SignHR deliberately does not send the terminal a timezone. Doing so would reset the device's clock, and every candidate value would be wrong in a way that silently shifts punches. The clock your installer set is the one that is used.
- One-way only. Employees, fingerprints and face templates are not pushed to the device; enrolment stays on the terminal.
- Because the device posts to a fixed path with no token, tenant resolution depends entirely on the serial number being registered correctly and being unique.
Questions
The protocol implementation is complete and tested, but it has not yet run against physical ZKTeco hardware. We would rather say that plainly than let you find out during a rollout. If you have ZKTeco terminals and want to use them, talk to us and treat the first device as a pilot — we will work through it with you.
Terminals that support the ADMS push protocol, which is the mechanism ZKTeco devices use to post records to a server rather than being polled. Firmware varies across the range, and since the adapter has not met real hardware yet, the honest answer is that your specific model needs confirming rather than assuming.
That is what the handshake requests, so on a compliant terminal punches deliver as they happen rather than in batches. This is the main behavioural difference from the eSSL integration, which posts on a short cycle.
The terminal holds them and delivers them on reconnect. SignHR explicitly asks for everything the device still has rather than only new records, which is what keeps an offline backlog from being discarded.
This integration feeds Time & Attendance.
Other integrations
Technical detail last checked against the product on 2026-08-07.