Biometric attendance without a static IP: how to solve the network problem once and for all

The industry's most common blocker

A customer wants biometric attendance across 5 franchises. Three use residential internet, one uses 4G and the fifth is on a job site. The local vendor replies: "we need a static IP at every site". And that's where the project dies: a static IP costs extra, sometimes isn't even available, and configuring 5 different networks isn't a plan — it's a ticket list.

The root problem is the connection model: if your software enters the customer's network to read the time clock, the customer's network has to be reachable from the outside. That requirement is what creates the whole problem.

The traditional options (and their real cost)

How push mode works (conceptual version)

Modern ZKTeco terminals support a mode in which the device is the one that reaches out: it connects to the cloud server's address and delivers its events — punches, heartbeats, syncs — on its own initiative, without anyone entering the network where it's installed.

The practical consequences:

• The customer's IP can be dynamic and change whenever it wants: it doesn't matter, because you never enter their network.
• 4G works: a router with a SIM is the most common installation on job sites and events.
• Multiple sites behind a single NAT: several terminals share the same internet connection without conflict.
• Zero network tickets: no ports to open, no firewall rules to negotiate with the customer.

What this means for your software

If you build the system (ERP, payroll, condo management), push mode changes the implementation conversation:

• Onboarding in hours, not weeks: the site technician just configures the server address on the terminal, and the serial number is registered in your platform.
• Multi-site without infrastructure: every branch is just one more terminal in the API, not a network project.
• Real-time events: you receive each punch the moment it happens; you don't import files at the end of the day.

Consuming the events from your backend looks like this:

import { createClient } from 'redis';

const sub = createClient({
  socket: { host: process.env.REDIS_HOST, port: Number(process.env.REDIS_PORT) },
  password: process.env.REDIS_PASSWORD
});

await sub.connect();

await sub.subscribe('punch_YOUR-SERIAL', (message) => {
  const event = JSON.parse(message);
  // mark attendance in your system, notify, trigger rules...
  console.log(event.pin, event.timestamp);
});

And if you'd rather query than listen, the REST API exposes per-terminal reports with date range and pagination.

What if the site's internet goes down?

That's the right question. Terminals store punches in local memory while there's no connection and re-upload them when the network comes back: the device tolerates temporary outages. For your software, the recommendation is simple: use real-time events for what's urgent (notifications, access) and the REST report as the source of truth for reconciliation.

Frequently asked questions