Case Study: One Device Pushing Attendance to Many Servers

The requirement

A client had a single biometric device but needed its attendance data delivered to two separate software systems. For example, an in-house HR platform and a third-party payroll vendor without installing a second device or splitting hardware between the two.

Why the dual API concept fits

Normally, one device is paired with one API and one callback URL: every punch is pushed to a single destination. The dual API concept removes that one-to-one limit. Instead of adding hardware, the client purchases an additional API license for the same physical device. Each API gets its own callback URL, and the device pushes every attendance record to all configured URLs at the same time, not in sequence, not on a delay.

This means the client didn’t need two devices at the door, two enrollment processes, or two sets of hardware maintenance. One punch, one device, multiple destinations.

How the flow works

Dual API flow: one punch delivered simultaneously to two configured callback URLs

1. The user punches at the device as usual, there’s no change to the end-user experience.
2. The device holds two (or more) configured APIs, each pointing at its own callback URL.
3. The attendance record is pushed simultaneously to every configured URL.
4. Each receiving server/software processes the record independently, one has no dependency on the other’s response.

Scaling beyond two

This isn’t capped at two destinations. The same concept extends to n APIs on a single device, each additional API is another shadow API with its own callback URL, and the device pushes to all of them at once. A client syncing attendance to HR, payroll, and a compliance dashboard, for instance, could configure three APIs on one device rather than running three separate readers.

What’s involved in purchasing

Implementation notes

• Each API/callback URL pair operates independently, a failure or slow response on one callback URL doesn’t block or delay delivery to the others.
• Because delivery is simultaneous rather than one server relaying to the next, there’s no dependency chain to manage between the receiving systems.
• This works well when two systems need the same raw attendance data for different purposes (e.g. payroll vs. access logging) rather than needing to talk to each other.
• Each API and its callback URL is configured independently from the dashboard, adding a shadow API doesn’t require any reconfiguration on the device itself.
• Use API Monitor to check delivery to each shadow API separately, since a delivery issue on one callback URL won’t necessarily show up on another.
• Because destinations are fully decoupled, dual API is also a clean way to run a migration in parallel, keep the existing system receiving data while a new system is validated, then retire the old callback URL once you’re confident in the switch.

Result

The client met the two-destination requirement using their existing single device, avoiding the cost and complexity of a second unit. The setup purchased only the incremental API license for the second destination, with the device cost applying once.