Event types determine which changes your webhook subscription receives.

When you create or update a subscription, add the event types you want to receive to the eventTypes array. You can subscribe to one or multiple event types in the same subscription.

For example:

{
"eventTypes": [
  "employee.person.v1",
  "employee.assignment.status.v1"
]
}

In this example, the subscription can receive events for changes to an employee's personal information and assignment status.

Your application must also have access to each event type included in the subscription. Access to one event type does not automatically provide access to another. See Webhooks API Overview for more information.

Available event types

Event types are currently available for two areas:

• Employee Demographics: Changes to employee personal information, assignments, status, pay rates, positions, supervisors, and other employee-related information.
• Punch Detail: Changes to worked shifts and pay type transactions.

Understanding event types and mutations

An event type identifies what changed, while the mutation field identifies how it changed.

A single event type can represent multiple types of changes. For example, employee.workedshift.v1 and employee.paytypetransaction.v1 can be delivered when a record is created, updated, or deleted.

Check the mutation field on the delivered event to determine what type of change occurred.

Employee Demographics

Employee Demographics events notify your application when supported employee or assignment information changes.

employee.person.v1

Notifies your application when an employee's core personal or contact information changes.

• When it's triggered:
  An employee's name or personal contact information is updated. This includes first, middle, last, preferred/display name, home address, home phone, mobile phone, or personal email.
• How to use it:
  Use this event to keep employee profile and personal contact information synchronized without repeatedly polling for changes.
• What you'll receive:
  The event contains supported person and contact information. Sensitive personal fields such as SSN, date of birth, marital status, ethnicity/race, gender, and suffix are not included in the event payload.

employee.assignment.v1

Notifies your application when a new employee assignment is created or an assignment-level change occurs that is not represented by one of the more specific assignment event types below.

• When it's triggered:
  An assignment is created for an employee, such as during a hire or rehire.
• How to use it:
  Use this event as a signal that a new employee assignment exists. It can be used alongside the more specific assignment events below to identify new-hire scenarios.
• What you'll receive:
  The event identifies the assignment using companyId and assignmentId. These identifiers can be used with the applicable read API when additional assignment details are needed.

employee.assignment.status.v1

Notifies your application when an employee's assignment status changes.

• When it's triggered:
  An employee's assignment status changes, such as when the employee is activated, placed on leave, or terminated.
• How to use it:
  Use this event when a downstream process needs to respond to an employee's status changing. For example, an integrated system may need to respond when an employee is terminated.
• What you'll receive:
  The payload includes the current status code and description, change-reason code and description, and the effective date of the change.

employee.assignment.payrate.v1

Notifies your application when an employee's pay rate changes.

• When it's triggered:
  A pay rate is added or updated on an employee's assignment, such as during initial pay setup, a pay increase, or a rate correction.
• How to use it:
  Use this event to keep downstream systems that depend on employee compensation information synchronized.
• What you'll receive:
  The payload includes the base rate, default hours, pay frequency, annual salary, rate-per-unit, pay type, and effective date.

employee.assignment.position.v1

Notifies your application when an employee's position or employment type changes.

• When it's triggered:
  The position code or employment type on an employee's assignment changes.
• How to use it:
  Use this event to keep systems that rely on employee position or employment information current, such as organizational or role-based systems.
• What you'll receive:
  The payload includes the position code, employment type code, and effective date of the change.

employee.assignment.reviewer.v1

Notifies your application when an employee's assigned reviewer changes.

• When it's triggered:
  A reviewer is assigned or changed on an employee's assignment.
• How to use it:
  Use this event to keep systems that depend on reviewer assignments or review routing synchronized.
• What you'll receive:
  The payload identifies the reviewer's assignment using companyId and assignmentId.

employee.assignment.supervisor.v1

Notifies your application when an employee's supervisor changes.

• When it's triggered:
  A supervisor or manager is assigned or changed on an employee's assignment.
• How to use it:
  Use this event to keep systems that rely on reporting relationships, organizational structure, or approval routing synchronized.
• What you'll receive:
  The payload identifies the supervisor's assignment using companyId and assignmentId.

employee.assignment.costcenter.v1

Notifies your application when the cost center allocation for an employee's assignment changes.

• When it's triggered:
  One or more cost center allocations on the employee's assignment are changed.
• How to use it:
  Use this event to keep systems that depend on an employee's cost center allocation current.
• What you'll receive:
  The payload includes the cost center code for each configured level, up to three levels.

employee.assignment.workcontact.v1

Notifies your application when an employee's work contact information changes.

• When it's triggered:
  An employee's work phone, extension, work mobile phone, or work email address is updated.
• How to use it:
  Use this event to keep employee directories, communication systems, or other integrations that rely on work contact information synchronized.
• What you'll receive:
  The event contains the employee's supported work contact information.

  • Personal contact information is handled separately by employee.person.v1

employee.assignment.worklocation.v1

Notifies your application when an employee's assigned work location changes.

• When it's triggered:
  The physical work location assigned to an employee changes.
• How to use it:
  Use this event for integrations or workflows that depend on an employee's work location.
• What you'll receive:
  The payload includes the work location's address, city, state, postal code, country, and county.

Punch Detail

Punch Detail events notify your application when supported worked-shift or pay-type transaction information changes.

These events can be used to receive changes closer to real time instead of repeatedly polling time card data.

employee.workedshift.v1

Notifies your application when a worked shift is created, changed, or removed.

A worked shift represents a span of worked time on an employee's time card, bounded by a clock-in and clock-out or missed punch, after payroll policy rules have processed the time into pay-relevant segments.

• When it's triggered:
  Punch activity creates, changes, or removes a worked shift. This can include clocking in or out, editing a punch, approving time, or a payroll-policy recalculation that changes how the shift's pay is calculated.
• How to use it:
  Use this event to track changes to worked time and estimated pay without repeatedly polling time card data.
• What you'll receive:
  The payload includes:
  • Shift start and end
  • Regular, overtime, and differential duration segments
  • Cost center allocation
  • Estimated wages calculated using the employee's pay rate and applicable payroll policy rules

Estimated wages are not final. Estimated wage values reflect payroll's in-progress calculation and are not final until payroll is processed.

employee.paytypetransaction.v1

Notifies your application when a pay-type transaction is created, changed, or removed from an employee's time card.

A pay-type transaction represents pay-type-coded time, such as vacation, sick, or other non-worked paid or unpaid time, after applicable payroll policy rules have been processed.

• When it's triggered:
  A pay type entry is added, edited, or removed from an employee's time card.
• How to use it:
  Use this event to track changes to non-worked paid or unpaid time without repeatedly polling time card data.
• What you'll receive:
  The payload includes:
  • Applicable date
  • Duration
  • Pay type
  • Cost center allocation
  • Regular, overtime, and unpaid duration breakdown
  • Estimated wages

Estimated wages are not final. As with worked shifts, estimated wage values are not final until payroll is processed.