Skip to main content
Biometric Attendance Push Bridge for Odoo — A build-to-order Odoo module that receives attendance punches and user records pu — 1/1Illustrative preview

A build-to-order Odoo module that receives attendance punches and user records pushed directly from biometric

time clocks and turns them into clean hr.attendance data.

ECOSIRE scopes, builds, installs, and supports it for your instance.

What is Biometric Attendance Push Bridge for Odoo?

A build-to-order Odoo module that receives attendance punches and user records pushed directly from biometric time clocks and turns them into clean hr.attendance data. ECOSIRE scopes, builds, installs, and supports it for your instance. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $999.00 USD; request a quote for a scoped proposal.

Key Features

Dedicated push-listener HTTP controller (auth='none', CSRF-exempt route) that accepts device handshake, options exchange, and attendance-log POSTs
biometric.device model tracking serial number, location, per-device timezone, firmware, and a live last-seen heartbeat with a state selection
biometric.punch staging model that stores every raw event with @api.depends resolution to hr.employee via a device-user-ID mapping table
Configurable punch-pairing engine that builds hr.attendance check-in/check-out records (first-in/last-out or strict alternation per shift)
Idempotent writes keyed on device serial + user + timestamp so a re-sent buffer after a network outage never double-counts a shift
Quarantine lane for unmatched, unknown-user, or duplicate punches so bad data never silently corrupts the timesheet
ir.model.access.csv plus record rules scoping devices and punches per company for correct multi-company isolation
ir.cron heartbeat monitor that flags any terminal that stops pushing within a configurable interval
Backend list/form/kanban views (XML for 17.0/18.0, OWL-compatible for 19.0) to register devices and audit the raw punch log
QWeb daily attendance-exception report listing missing check-outs, orphan punches, and out-of-window events
Per-device timezone normalization so punches land at the correct UTC instant regardless of terminal clock settings
Automated action / server action hooks to trigger notifications or downstream syncs when exceptions are detected
Full XML-RPC/JSON-RPC exposure of devices, punches, and resolved attendance for payroll or middleware integration
Optional employee auto-provisioning from pushed user records, mapping device enrollment IDs to hr.employee on first sight

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

  1. 1

    You order

    Start with a one-time build price. We scope it with you at kickoff.

  2. 2

    We build & install

    ECOSIRE builds, configures and installs it on your Odoo.

  3. 3

    Go live + support

    You go live in about one working week, with two weeks of go-live support. Defects in the code we deliver are fixed free of charge.

Technical Specifications

Odoo Compatibility
Odoo 17, Odoo 18, Odoo 19
Editions
Enterprise & Community
License
Licence confirmation required
Python Requirement
Python 3.10+
Database
PostgreSQL 12+

About this Product

Most teams that adopt biometric fingerprint or face terminals for time tracking hit the same wall: the devices happily record punches, but getting that data into Odoo is a manual export-import chore. Odoo's native hr_attendance module is built around kiosk check-in/out and manual entry — it has no listener for the "push" protocol that low-cost biometric terminals use to POST punch events to a server over HTTP. Without a bridge, someone downloads logs to a spreadsheet nightly, reconciles employee IDs by hand, and payroll inherits every typo. That is exactly where Odoo runs out of road: it can store attendance, but it cannot ingest a device push stream on its own.

We build a dedicated HTTP endpoint inside Odoo that speaks the terminal's push dialect. The controller (a subclass of http.Controller with an auth='none', CSRF-exempt route) accepts the device handshake, options exchange, and attendance-log POSTs, parses the raw punch records, and writes them through the ORM. A new biometric.device model (models.Model with fields for serial number, location, timezone, last-seen heartbeat, and a state selection) represents each registered terminal, and a biometric.punch staging model captures every raw event before it is resolved to an hr.employee through a device-user-ID map. Matched punches are paired into hr.attendance check-in/check-out records using configurable pairing logic (first-in/last-out per day, or strict alternation), while unmatched or duplicate events are quarantined for review instead of silently corrupting the timesheet.

Because this is a real module and not a script, it ships with the full Odoo surface: ir.model.access.csv plus record rules so HR sees only their company's devices, backend list/form/kanban views (XML for 17/18, OWL-compatible for 19) to register terminals and browse the raw punch log, a QWeb report for a daily attendance-exception sheet, and an ir.cron heartbeat monitor that flags any device that stops pushing. Everything the endpoint receives is also reachable over Odoo's own XML-RPC/JSON-RPC API, so downstream payroll or middleware can read the same records. We handle multi-company scoping, timezone normalization per device, and idempotent writes so a device that re-sends its buffer after a network outage never double-counts a shift.

Delivery is build-to-order. After a short scoping call we confirm your device push protocol variant, Odoo edition (Community or Enterprise) and version (17.0/18.0/19.0), employee-mapping rules, and multi-company layout, then build against a staging copy of your database, run UAT with your real terminals, and cut over with a rollback plan. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); additional device protocol variants, multi-company/multi-timezone rollouts, payroll-system integration, and historical punch-data migration increase the quoted scope.

What you get

  • Installable Odoo module source code targeting your confirmed edition and version (17.0/18.0/19.0), with a clean __manifest__.py and declared dependencies
  • Installation and configuration on your staging environment, including device-endpoint wiring and employee-mapping setup
  • Technical documentation: models, controller routes, security rules, and the push-protocol handling notes
  • User guide plus a live training session for HR/admin staff on registering devices and resolving attendance exceptions
  • UAT on a staging copy of your database with your real terminals, plus a documented rollback plan for cutover
  • Post-go-live support window for defect fixes and configuration adjustments
  • Git repository handover with full commit history and tagged release
  • Data-migration pass for historical punch records where in scope

Who this is for

HR / Payroll Manager

Runs monthly payroll off attendance data and is tired of reconciling device exports by hand. Needs punches to flow into hr.attendance automatically, with a clear exception report for missing check-outs before payroll close.

Odoo System Administrator

Owns the Odoo instance and its uptime. Needs a maintainable module with proper security rules, a device heartbeat monitor, and idempotent writes — not a fragile cron that scrapes a spreadsheet every night.

Operations Manager (multi-site)

Oversees several branches each with its own terminal and timezone. Needs per-device registration, multi-company scoping, and one consolidated view of who clocked in where, without manual per-site imports.

IT Integrator / Implementation Partner

Delivering an Odoo rollout for a client and needs the biometric layer handled by specialists. Wants clean source, XML-RPC/JSON-RPC access to the records, and a documented handover to fold into the wider project.

How Biometric Attendance Push Bridge for Odoo Compares

CriterionECOSIRECustom BuildCompetitorOdoo Native
Device push ingestionPurpose-built HTTP listener for your terminals' push protocolYou design and debug the protocol handling from zeroFixed protocol support; may not match your device modelNone — no push endpoint exists in core
Employee mappingDevice-user-ID map resolving to hr.employee, with quarantine for unknownsBuild your own mapping and error handlingBasic mapping; exception handling variesManual entry only
Duplicate / re-send safetyIdempotent writes keyed on serial+user+timestampDepends entirely on your implementationOften not guaranteedNot applicable
Multi-company & timezoneRecord-rule scoping plus per-device timezone normalizationYou implement scoping and TZ logic yourselfFrequently single-company / single-TZ assumptionsCompany field exists but no device layer
Version & edition fitBuilt and tested for your exact 17/18/19, Community or EnterpriseYour responsibility to target and testPrebuilt for specific versions; upgrades lagShips with the version you run
Exception reportingQWeb daily exception sheet plus device heartbeat cronBuild reports and monitoring separatelyLimited or absentNo device-level exceptions
Support & handoverTraining, post-go-live support window, full git repo handoverIn-house knowledge onlyVendor support ticket queueCommunity/Enterprise support, not device-specific
Total cost profileFixed quote from an indicative $999 base after scopingOpen-ended developer time and maintenanceLow list price but integration and fit costs hiddenIncluded, but does not solve the problem

Frequently Asked Questions about Biometric Attendance Push Bridge

How long does delivery take?

This is a build-to-order module, not an instant download. Typical delivery is one working week from confirmed scope. The exact timeline depends on how many device protocol variants, companies, and timezones are in play, plus whether historical data migration is included. We agree the timeline in writing before work starts.

Does this work with my specific biometric terminals?

It targets terminals that use an HTTP push protocol to POST punch events to a server. During the scoping call we confirm the exact protocol variant your devices speak and build the listener to match. If you run mixed models, each additional protocol variant is factored into the quote.

Which Odoo versions and editions are supported?

We build for Odoo 17.0, 18.0, or 19.0, on Community or Enterprise. We confirm your exact version and edition at scoping and build against a matching staging copy, since view syntax (OWL in 19.0) and some HR behaviors differ between releases.

How does pricing and scoping work?

Pricing starts from $999 as an indicative figure for a single-company base scope. It is not a fixed price. After a short scoping call we assess your devices, edition/version, mapping rules, and multi-company needs, then send a fixed written quote for the agreed scope before any work begins.

What about support and updates after go-live?

Every build includes a post-go-live support window for defect fixes and configuration adjustments. Because you receive the full source and git repository, you can also maintain it in-house. We offer ongoing support and version-upgrade work (for example moving from 17.0 to 19.0) as a separate arrangement.

Will re-sent data create duplicate attendance records?

No. Writes are idempotent, keyed on device serial, user, and timestamp, so a terminal that re-sends its buffer after a network outage will not double-count a shift. Unmatched or duplicate events are quarantined for review rather than silently written.

Can we read the attendance data from other systems?

Yes. Devices, raw punches, and resolved hr.attendance records are all standard Odoo models, so they are fully available over Odoo's XML-RPC/JSON-RPC API for payroll systems, BI tools, or custom middleware.

Request a quote

Biometric Attendance Push Bridge

A build-to-order Odoo module that receives attendance punches and user records pushed directly from biometric time clocks and turns them into clean hr.attendance data. ECOSIRE scopes, builds, installs, and supports it for your instance.

  • Dedicated push-listener HTTP controller (auth='none', CSRF-exempt route) that accepts device handshake, options exchange, and attendance-log POSTs
  • biometric.device model tracking serial number, location, per-device timezone, firmware, and a live last-seen heartbeat with a state selection
  • biometric.punch staging model that stores every raw event with @api.depends resolution to hr.employee via a device-user-ID mapping table
  • Configurable punch-pairing engine that builds hr.attendance check-in/check-out records (first-in/last-out or strict alternation per shift)

Request a Quotation

Tell us about your Biometric Attendance Push Bridge requirements and we'll send pricing, licensing options and a tailored proposal — usually within one business day.

No payment now. This sends a quote request to our team — we'll follow up by email with pricing and next steps.