Skip to main content
Nine event types. This is the complete list — no others exist.

​
The payload shape

Every event carries the same envelope:
​
string
The event type. Matches the X-Ontime-Event header.
​
uuid
The employee the notification is for — usually the person the event happened to, not the person who caused it.
​
object | null
A reference to the affected record: { "kind": "...", "id": "..." }. null for events with no navigable target.
​
string
A short human-readable label.
​
string
ISO 8601, when the event was enqueued.
The payload does not contain the domain object. There is no leave request, no payslip, no message body. Use ref.id to fetch what you need.It also does not carry the actor — who approved, who sent. Only the recipient.

​
The events

A leave request reached its final approval. For a type requiring an HR step, this fires when HR approves, not when the manager does.ref.kind is leave; ref.id is the leave request. recipientId is the employee who requested the leave.
A leave request was rejected, at either stage.
An attendance correction reached final approval — and therefore the affected day record has already been rewritten. If you cache attendance, this is the signal to re-read that date.ref.kind is regularization.
An attendance correction was rejected. No day record changed.
An overtime request was approved. The day record has been re-derived with the approved minutes, and if the day was a holiday or the employee’s weekly off, comp-off has been credited.ref.kind is overtime.
An overtime request was rejected.
A payroll cycle was disbursed and this employee’s payslip exists. Fires once per employee in the cycle.
This event is gated by the organization’s payslip notification preference. With that toggle off, the payslips are still created but no webhook fires. If your integration depends on this event, confirm the toggle is on.
A Form 16 batch was distributed and this employee’s document is in their vault. Gated by the Form 16 notification preference.
Somebody sent this employee a message in a manager-report thread. Gated by the messages preference.ref.kind is message.

​
What does not fire a webhook

OnTime raises more in-app notification types than it maps to webhooks. The following happen and are visible in the app but never reach a webhook:If you need any of these, poll for them.
There is also no event for a punch. Attendance changes are not pushed; a regularization.approved is the closest signal that a past day changed, and nothing signals an ordinary punch. Poll GET /api/public/v1/attendance for a date.

​
Preference gating in general

Webhook delivery rides the same path as in-app notifications, so organization notification preferences silence webhooks too. Turning off a category in Settings → Notifications stops the corresponding webhook from being enqueued at all.This is easy to miss when debugging “my webhook stopped firing”. Check the preferences before the delivery log.