Added contractor lifecycle webhooks for future-dated transitions
We've added four contractor webhook eventscontractor.deactivation_effective, contractor.deactivation_cancelled, contractor.reactivation_effective, and contractor.reactivation_cancelled. Read more in our Contractor Events guide.
| Webhook event | When it fires |
|---|---|
contractor.deactivation_effective | When the dismissal takes effect (the day after end_date). Sent immediately if the dismissal's end_date is in the past. If the dismissal's end_date is today or in the future, this event is sent on the day after the end_date. |
contractor.deactivation_cancelled | When a pending dismissal is cancelled via DELETE /v1/contractors/{contractor_uuid}/termination. |
contractor.reactivation_effective | When a rehire takes effect (on start_date). Sent immediately for current- and past-dated rehires. Sent on the effective date for future-dated ones. |
contractor.reactivation_cancelled | When a pending rehire is cancelled via DELETE /v1/contractors/{contractor_uuid}/rehire. |
Clarification for existing events
contractor.deactivatedandcontractor.reactivatedfire at record time—the moment the dismissal or rehire is recorded, regardless of when the change actually takes effect. If you rely on these events to signal that the status transition has already taken effect, subscribe to the corresponding_effectiveevent instead.
When a scheduled dismissal is cancelled,contractor.deactivation_cancelledis now emitted instead ofcontractor.reactivated.
Why this matters
If your integration keys off the exact point a contractor becomes active or inactive—such as for time tracking, benefits, access provisioning, or reporting—you need a signal at the effective date, not at record time. The new _effective events fire on the effective date, closing the gap for future-dated transitions. The new _cancelled events give you a clean signal for when a pending dismissal or rehire is called off.
Read more in our Contractor Events and Deactivate a contractor guides.