Guide · Explainer

What is ADMS / iClock push, and why does it decide whether your attendance needs a PC?

Open the Comm menu on almost any eSSL or ZKTeco terminal and you will find a screen called ADMS, Cloud Server Setting or, on older units, iClock. It is the single most consequential setting on the device, and the manuals explain it in one line. This page explains it properly: what the terminal does when the setting is on, what the server has to do in return, what it makes possible, and the four things it cannot do that vendors' brochures skip.

Get started Talk to sales

ADMS, also called the iClock protocol or ZKTeco PUSH SDK, is a method by which a biometric terminal sends its own data to a server over ordinary HTTP. With ADMS enabled, the terminal dials out to the server address you set, announces its serial number, uploads each punch as it happens, and polls every few seconds for commands such as adding a user, clearing data or opening a door. Because the terminal starts every conversation, it needs no static IP, no port forwarding and no PC at the site, and it buffers punches on its own memory while the internet is down. ADMS is the native protocol of ZKTeco hardware, which is what eSSL terminals and many rebranded units are built on. Realtime terminals use a different push protocol of their own.

Outbound only

the terminal starts every request; nothing has to reach into your network

Every few seconds

the device asks the server whether there is a command waiting for it

Buffered

punches taken during an internet cut are stored on the device and sent when the line returns

One server

a terminal pushes to a single address; whoever holds that address holds the punches

Three ways to get a punch out of a terminal

A biometric terminal is a small computer with a fingerprint or face sensor and a table of punches. There are only three ways to get that table out, and every attendance product in India uses one of them, whatever it calls itself.

USB download. Walk to the machine, insert a pen drive, choose Download Attendance, walk to the PC, import. Reliable, offline, and someone's job every week. Still the norm at a surprising number of small factories.
SDK or database pull. Software on a PC in the same network opens a connection to the terminal's SDK port (4370 on ZKTeco-family devices) and reads the table. This is what desktop eTimeTrackLite, Realtime's Realsoft and most HR suites' sync agents do. It works while that PC is on, the terminal's IP has not changed, and nobody has moved the machine to another switch. If the software runs outside your network, it also needs a static public IP or a VPN so it can reach in.
Push. The terminal itself connects out to a server and delivers each punch as it happens, then keeps asking whether the server has anything for it. Nothing at the site does any work; the terminal is a client like a phone app. ADMS is ZKTeco's name for this; iClock is the older name and the one still in the URLs the device calls.

What actually happens when ADMS is on

The mechanics are simple enough to describe in full, and knowing them makes every troubleshooting session shorter.

Handshake. After a restart, or on a timer, the terminal sends a request to the server's iClock endpoint carrying its serial number and a few facts about itself. The server answers with its options: the timestamp it last received, how often the device should report, the server version. From this moment the terminal considers itself connected.
Uploads. Each punch is sent within seconds as an attendance-log record: the user ID, the time on the device's clock, the verification method (fingerprint, face, card, password) and a status such as check-in, check-out, break-out or overtime-in. Enrolment events and admin actions go up as operation logs.
Polling. Every few seconds the terminal asks the server whether there is a command waiting. The answer is usually nothing. When an administrator adds a user in the browser, blocks a person, or presses Unlock, the server queues a command, the terminal collects it on its next poll, executes it and reports the result.
Recovery. The server tells the terminal the timestamp of the last record it received. If the internet was down for a day, the terminal has been storing punches in its own memory the whole time, and on reconnection it sends everything after that timestamp. Most eSSL and ZKTeco models store tens of thousands of transactions; the data sheet gives the exact figure.
Registration. The terminal identifies itself by serial number and nothing else. The server decides whether it knows that serial. If it does not, it still answers, and the punches go nowhere. This is why the serial has to be registered in the software before the device is repointed.

Why this decides whether you need a PC

The push model moves all the work from your site to the vendor's server. That is the whole reason cloud attendance without a PC exists, and it is why the first question to ask any attendance vendor is which of the three methods they use for your terminal.

Nothing to install, patch, licence or reboot at the site. The terminal is the only piece of equipment, and it was already there.
No dependency on the office network's layout. The device can be on Wi-Fi, on a dynamic IP, behind a mobile hotspot at a construction site. It only has to reach out.
Multi-site for free. Twenty terminals in twenty cities each push to the same server; the head office sees one register. With a pull model, each site needs its own reader PC or a VPN.
Commands travel back. Because the terminal keeps asking, the server can push a new employee, block a leaver, or open a door, without anyone at the site. Pull-based integrations read; they rarely command.
The failure modes shrink to two: the terminal has no power, or it has no internet. Both are visible from the browser as an offline flag and both are fixed by someone at the site checking a cable.

Four things ADMS cannot do, which brochures skip

Push is the right architecture and it has limits. Knowing them in advance is what separates a smooth cutover from a bad month.

One server per terminal. The device has a single server-address setting. If a terminal is already pushing to eSSL Cloud or a dealer's hosted server, repointing it stops that feed. There is no fan-out; if two systems need the punches, one of them must receive them from the other, for instance through an API.
The device's clock is the truth. Punches carry the time on the terminal, in the terminal's time zone. A device set to the wrong zone, or drifting because it has been off the network for months, produces punches that look missing or early. Set the time zone on the device, and check it after every power cut.
Templates are format-specific. A fingerprint template from one algorithm version cannot be loaded into a terminal running another. ADMS can move user profiles and, between compatible iClock terminals, compatible templates. It cannot turn a ZKTeco fingerprint into a Realtime one, and it cannot move a face template captured on one sensor generation to a different one. Expect re-enrolment when hardware generations differ.
"ADMS" on the menu is not one dialect. Firmware lines differ in the fields they send, the commands they accept and how they encode names. This is why serious vendors confirm the exact model and firmware and prove a test punch rather than publishing a list of 200 brands. AionHRMS does the confirmation before rollout and says so on every page.

Which brands use it, and which do not

ADMS is ZKTeco's protocol. Any terminal built on ZKTeco hardware or firmware is a candidate, whatever badge is on the front. Any terminal built on somebody else's platform is not, however similar it looks.

ZKTeco: native. Menu, Comm., Cloud Server Setting on current firmware; ADMS on older.
eSSL: native, because eSSL terminals are ZKTeco hardware sold and supported in India. The eSSL X990, K30, MB and iFace lines expose the ADMS screen on most firmware.
CP Plus and other resellers: model dependent. Some units are ZK-platform and push cleanly; some expose an IP and port with no domain name; some cannot push at all. Check the Comm menu before assuming.
Realtime: a different push protocol of Realtime's own. Same architecture (the device dials out), different messages. AionHRMS implements it separately.
Matrix COSEC, Mantra, Secureye, BioMax: their own platforms, not ADMS. AionHRMS does not implement them today and does not list them as supported.

Frequently asked questions

Is ADMS the same as iClock?

Yes, for practical purposes. iClock is the older name and still appears in the paths the device calls; ADMS (Automatic Data Master Server) is what the menu on eSSL and ZKTeco terminals calls the same feature; ZKTeco's developer material calls it PUSH SDK. All three describe a terminal that sends its data to a server and polls for commands.

Does ADMS need a static IP?

No. The terminal makes outbound connections to the server, like a browser opening a website. Your site can be on a dynamic IP behind an ordinary router. Only pull-based integrations, where software outside your network reaches in to read the device, need a static IP or VPN.

What port does ADMS use?

Whatever port the server publishes; the number goes in the device's Server Port field. It is plain HTTP from the device's side, which is why the traffic passes through nearly every office router without configuration. The SDK port (4370 on ZKTeco-family devices) is a separate thing used by pull-based software on the LAN and is not involved in push.

What happens to punches when the internet is down?

The terminal keeps verifying people and stores each punch in its own memory. When the connection returns, the server tells it the timestamp of the last record it holds and the terminal uploads everything since. Nothing is lost unless the device's memory fills, which on most models takes tens of thousands of punches.

Can one terminal push to two servers at once?

No. There is one server-address setting. If two systems need the punches, one must receive them and pass them on, for example through the receiving system's API. A desktop application reading the device over the LAN via SDK is a separate mechanism and can run alongside the push.

Does every device with an ADMS menu work with every cloud attendance software?

No. The menu is the same; the firmware dialects are not. Fields, commands and encodings differ between firmware lines. Ask the vendor to confirm your exact model and firmware and to prove a test punch before you sign. AionHRMS confirms every model before rollout rather than publishing a brand list.

Find out whether your terminal can push

Send the model, serial, firmware and a photo of the Comm menu. We tell you yes, no or test-first, before anything is bought.