All modules Campus Operations

Biometric Attendance software for Indian schools

Token-protected student IN punch bridge

Feature identity
Biometric Attendance
An illustration, not a screenshot. The interactive example below shows what this capability actually does.

Biometric Attendance in a school workflow

Illustrative device event

Incoming eventBiometric AttendanceExample only

Event evidence 01Per-device ingest tokens — rotate to instantly revoke a compromised device
Event evidence 02A matched student's IN punch can mark present without replacing an existing manual mark
Event evidence 03Unmatched punches are held for review, never silently dropped

Rollout conditionsA plan that includes Biometric Devices, plus compatible school-supplied device middleware

Code-native illustrative example · not live product UI · no customer dataExample labels and outcomes come from this capability's reviewed catalogue record.

Product scope

What it does

A compatible reader or school-supplied device middleware can post punches to a per-device token webhook. A matched student's IN punch can mark that student present without overwriting a teacher's existing manual register; OUT punches remain in the punch log. Vidyapeeth360 provides the generic bridge, not a bundled vendor-specific biometric SDK.

The school problem

School teams need a dependable way to handle Biometric Attendance: Token-protected student IN punch bridge. The required records, assigned roles and review boundary must remain explicit.

Day-to-day work

How your school uses it day to day

Token-protected student IN punch bridge.

Per-device ingest tokens — rotate to instantly revoke a compromised device
A matched student's IN punch can mark present without replacing an existing manual mark
Unmatched punches are held for review, never silently dropped
Compatible device middleware is required; vendor SDK integration is not bundled

Operational result

What your school gets

A reviewable device-punch stream where matched student IN events may mark present without overwriting a teacher's register.

Access and ownership

Who typically uses it

Attendance administrator
Device administrator
Class teacher
School administrator

What each person can actually see depends on the role you give them and which classes or records you assign.

Availability and setup

What to confirm before rollout

Included from Enterprise

Token-protected student IN-punch bridge for compatible attendance devices.

A plan that includes Biometric Devices, plus compatible school-supplied device middleware
Your attendance device vendor must supply compatible bridge software — none is bundled
Requires compatible device middleware. The product exposes a token-protected student IN-punch bridge, not a bundled vendor SDK.

Flagship workflow deep dive

Biometric & Device Attendance Bridge

Every attendance mark keeps its source.

Combine teacher-marked day or period registers with compatible biometric, RFID or QR punch evidence. Device punches remain subordinate to existing teacher marks, and unmatched identities stay visible for review instead of disappearing.

Interactive operating model

Two sources, one governed register

See how teacher intent and device evidence meet without allowing a punch to erase a human-marked state.

Illustrative workflow · no customer data

Stage 1 of 5

Roster resolved

The current class-section roster and teacher scope establish who can be marked.

Control point

A device identity is never allowed to widen the teacher's record access.

Evidence retained

Enrolment-backed roster and teaching assignment.

Core workflows and features

The operational work behind the promise

Day and period registersRecord present, absent, late or leave against the authorised class-section roster.
Teacher-section boundaryLimit classroom staff to the sections their current teaching assignments permit.
Idempotent register saveSubmit an offline-tolerant register without creating a duplicate mark on a safe retry.
Correction evidenceRetain the before-and-after state when an authorised teacher re-marks a saved cell.
Registered device identityGive each compatible device or middleware connection a tenant-scoped ingest token that can be rotated.
Provider-agnostic punch bridgeAccept the supported biometric, RFID or QR identity event through school-supplied compatible middleware.
Conservative IN handlingA matched student's IN punch may fill an empty present mark; it cannot replace an existing teacher mark.
Evidence-only OUT handlingKeep OUT punches in the punch log rather than using them to rewrite the classroom register.
Unmatched review queueHold an unresolved admission number or device identity for staff review instead of dropping the event.
Attendance analysisReview daily, monthly, class, chronic-absence and configured threshold views from saved attendance records.

Bounded attendance assistance

Explain the register; never rewrite it through AI.

Aira may explain a permitted attendance summary through the separately enabled assistant surface. Deterministic attendance rules can identify saved-register exceptions or configured shortfall cases for staff review.

Explain a permitted attendance aggregate using the source record returned by an authorised tool.
Flag chronic, at-risk or configured board-threshold cases from deterministic attendance calculations.
Queue an eligible guardian alert only through the configured communication, consent, opt-out and quiet-mode path.
Keep device mapping and unmatched-punch resolution with an authorised operator.

Human boundary

Aira does not create, correct or approve attendance. A teacher saves the register, an operator resolves unmatched punches, and a device event never overrides an existing manual mark. Geo-fenced attendance is not part of this module.

Key daily uses

What the school team does here

Mark and, when authorised, correct a class or period register.
Review missing registers and current attendance trends.
Resolve unmatched device punches against the correct tenant identity.
Rotate a compromised device ingest token.
Review configured shortfall cases before any family follow-up.

Used by

Class teacher
Attendance coordinator
Vice principal
Principal
Tenant administrator
Device operator
Parent or guardian as an alert recipient

Actual access follows the school's plan, role permissions and record scope.

Measurable operating indicators

Metrics to track — not guaranteed ROI

Establish a baseline before rollout, agree the reporting period, then compare the school's own source evidence.

Attendance visibility

Saved daily, rolling and class attendance rates

Uses the recorded register and keeps missing-register context separate from absence.

Device matching quality

Matched versus unmatched punches by registered device

Shows whether identity mapping needs attention before a device bridge is trusted operationally.

Follow-up readiness

Chronic, at-risk and configured threshold-shortfall case counts

Prioritises human review without presenting an AI prediction as an attendance fact.

Prerequisites and availability

Confirm the operating context before rollout.

Biometric attendance on a plan that includes it · compatible device middleware required

Confirm a compatible reader or school-supplied middleware that can post the supported event shape.
Register each device, protect and rotate its ingest token, and map student admission numbers within the correct tenant.
The generic bridge is not a bundled vendor-specific biometric SDK and does not include hardware.
Staff punches need the separate HR & Payroll workspace, which is still rolling out school by school, and do not automatically become payroll attendance.
Geo-fenced attendance is not included; where a supported workflow offers location-based proof, ask us to map it to your school.

Connected operating context

Available workflows

These are the documented neighbouring capabilities that school teams may review with this module. A related page does not imply that every hand-off is automatic or enabled in every plan.

Explore all modules

Buyer questions

Frequently asked questions

The questions school owners ask before they subscribe: what it does, who can see it, and what to set up first.

Do you supply the biometric hardware?

No. This is a provider-agnostic bridge: your school supplies a compatible reader or middleware that can post the supported event shape, and each device gets a tenant-scoped ingest token you can rotate. No vendor SDK is bundled and no hardware is included.

Can a device punch overwrite a teacher's attendance mark?

Never. A matched IN punch may fill an empty present mark only. An existing teacher mark always wins, OUT punches stay evidence in the punch log, and an unmatched identity goes to a review queue instead of being dropped.

Does Biometric Attendance work on its own?

Student Attendance, QR Attendance, RFID Attendance, Parent Notification are the documented neighbouring capabilities. They help a school evaluate the surrounding hand-offs, but a related page does not mean every integration is automatic or included in every plan.

What should our school prepare before enabling Biometric Attendance?

Your attendance device vendor must supply compatible bridge software — none is bundled. A plan that includes Biometric Devices, plus compatible school-supplied device middleware. Requires compatible device middleware. The product exposes a token-protected student IN-punch bridge, not a bundled vendor SDK.

Is AI used in Biometric Attendance?

No AI capability is asserted for Biometric Attendance. Its documented work remains controlled by school records, roles and permissions.

How do we confirm the plan and implementation scope?

Biometric Attendance is included from Enterprise in the current public plan matrix. Final rollout scope, services and external dependencies are confirmed in your written proposal.

See the Campus Operations workspace Compare plans and commercial costs

See it in your school context

Run biometric attendance the connected way.

See how this workflow fits your school's current records, roles, plan and rollout requirements.