Webhooks
Keep the attendance software you already run. Onetap records attendance at the door and pushes each event into your system as it happens.
ProposedNot yet callable
This is the proposed design for institution webhooks. Nothing here is live yet — it is published so institutions can plan integration work and tell us where it breaks against their existing systems.
What arrives at your endpoint
Register a URL, verify the signature, and every tap at the door lands in your system within seconds — in one envelope shape for every event type.
{ "id": "evt_01J8ZC4K2M", "type": "attendance.recorded", "created_at": "2026-07-19T09:15:22Z", "data": { "record_id": "att_7d3e91", "status": "present", "student": { "external_id": "2024CS118" }, "session": { "course_code": "CS101" } }}How it works
Most institutions already own an attendance system — an ERP, an LMS, or something built in-house. Replacing it is rarely worth it. Webhooks let Onetap be the capture layer while your system stays the record of truth.
Student taps / is detected at an R-series device
│
▼
Onetap verifies the presence and writes the record
│
▼
POST to your registered endpoint ──► your attendance system
│ │
└──────── 2xx acknowledges ◄───────────┘Why not polling
- Nothing to schedule. Events arrive within seconds of the tap instead of whenever the next cron ran.
- No wasted requests. A polling job asks “anything new?” thousands of times a day and is told no.
- Outages are handled for you. If your endpoint is down we retry, so a deploy does not lose a morning of attendance.
If you do need to reconcile in bulk — a nightly catch-up, or a first import — use the Attendance API alongside webhooks rather than instead of them.
Where to next
- Quickstart — register an endpoint and receive your first event.
- Authentication — verify signatures. Do this before trusting a payload.
- Events — every event type and the payload shape.