In a biometric attendance system, accurately identifying whether a punch is an IN or OUT entry is critical for ensuring proper attendance tracking. At Cams Biometrics, we offer flexible ways to determine the punch state—both at the hardware level and at the admin portal (API) level.
This article explains how punch states are recorded, what options developers can configure, and what important technical constraints must be considered to ensure reliable performance in real-time systems.
🛠️ 1. Punch State at the Hardware Level
On most biometric devices, all punches are recorded as “Check In” by default.
If a user wants to record a “Check Out” or any other custom state, they must manually select the appropriate punch mode on the device (e.g., by pressing a “Check Out” button or using a touchscreen option) before punching.
✅ This setup works well in environments where users are trained to select the correct punch mode at the device.
❌ Important: Selecting the state automatically at the hardware level is not possible. Biometric devices do not maintain any business logic. Developers must ensure punch states are correctly processed by the connected software or API logic.
🌐 2. Punch State at the Cams Portal Level (Automation Options)
To simplify user experience and automate punch state classification, developers integrating with the Cams Web API can choose from the following server-side logic options. These rules are applied after the punch is recorded in the device.
📌 Option 1: Actual
- The exact punch state (IN/OUT) selected by the user at the device is passed through to the server.
📌 Option 2: First In Rest Out
- The first punch of the day is marked as IN.
- All subsequent punches within the same 24-hour period for the same user are marked as OUT.
- Ideal for systems where users don’t manually select the punch type.
📌 Option 3: ZigZag
- Punches alternate between IN and OUT throughout the day.
- The first punch is IN, second is OUT, third is IN, and so on.
- The logic is maintained for each user based on the past 24 hours of their activity.
ℹ️ Both
First In Rest OutandZigZagmodes require access to the last 24 hours of punch history to function accurately.
⚠️ Key Constraints to Be Aware Of
While these auto-logic options simplify integration, there are important limitations to understand:
❗ 1. No Permanent User Data Storage
Cams Biometrics does not store user or punch data permanently. For First In Rest Out and ZigZag, we temporarily store punch history for the last 24 hours only.
If a machine is offline for more than 24 hours, earlier punches are no longer available to evaluate the next punch correctly. This may lead to incorrect classification (e.g., treating the second punch as IN instead of OUT).
❗ 2. Logic Works Per Device Only
These punch state logics are applied on a per device per user basis. If a user punches on multiple devices, the system does not cross-reference across machines. This will cause logic failures for multi-device use cases.
❗ 3. Machines Must Connect at Least Once Every 24 Hours
For punch state automation to work reliably, machines must come online and sync at least once in every 24 hours. Otherwise, Cams servers won’t be able to maintain the required short-term punch history.
❗ 4. Not Suitable for Shift-Based Attendance
Punch state automation is based only on last 24 hours of data, and the classification is done within the same calendar day as the punch.
If you are handling shift-based attendance, especially overnight or flexible shifts, we strongly recommend that you do not rely on the punch state from the API. Instead, build your own logic within your system to interpret punches based on your shift definitions.
🛠️ Cams does not currently support punch state automation based on shift timings. That logic must be implemented in your designated attendance management software.
✅ Best Practices & Recommendation
Before enabling automatic punch state logic (First In Rest Out or ZigZag), ensure that:
- Users consistently punch from one assigned machine.
- Each machine connects to the server at least once every 24 hours.
- You understand the behavior and limitations of these logic modes to avoid incorrect punch interpretation.
🛑 Do not activate these options unless your setup fully complies with the above conditions—improper use may lead to attendance miscalculations for your customer.
🚀 Cams Offers No-Code or Instant Integration
To simplify your development process, Cams offers plug-and-play (no-code) integration options as well as full custom support.
If needed, our team can:
- Develop custom logic based on your system’s workflow.
- Provide ready-to-install integration code for any server language (PHP, Node.js, Java, Python, .NET, etc.) and any database (MySQL, PostgreSQL, SQL Server, etc.).
Simply let us know your tech stack, and we’ll help you integrate seamlessly.
