Time Clock: New Time Activity Webhook Events

Time Activity webhooks now cover the full request and timesheet-approval lifecycle, not only completed punches.

Twelve events that were listed as coming soon are live. Subscribe on the existing time_activity webhook (same Time Clock entityId) and add the new names to eventTypes. Existing subscriptions are unchanged until you opt in.

New Events

Pending requests and specific declines

• user_add_request — user submitted an add request (includes the requested timeActivity)
• user_edit_request — user submitted an edit request (requested times, not the saved timesheet value)
• user_delete_request — user submitted a delete request (timeActivityId only)
• admin_declined_add_request / admin_declined_edit_request / admin_declined_delete_request — admin declined that request

Timesheet period (activityType: timesheet_period)

• admin_day_locked / admin_day_unlocked — one event per affected user and date range
• user_timesheet_submitted / user_timesheet_unsubmitted
• user_timesheet_approved / user_timesheet_reopened — only when that user's status actually changed

Key Features

• Same webhook type: no new featureType. Add the event names to a time_activity subscription
• Correct eventTimestamp only on these new payloads (the deprecated evnetTimestamp spelling is not sent)
• admin_declined_request stays so current subscribers keep working. New integrations should use the three specific decline events. A declined shift or break request publishes both the generic event and the matching specific event — do not subscribe to both. Time-off declines still send only admin_declined_request
• Lock/unlock from the Lock Days API fires the same period events

For payload examples and a subscribe curl, see the Time activity webhook guide.