Employee data webhooks: table entry events payload updated

The table.entry.created and table.entry.updated webhook events now return cleaner payloads (starting March 24, 2026). The row identifier fields are now included only when relevant to the table type.

What changed

• The id and effectiveDate fields are now optional and returned based on the table type.
• Historical tables: include effectiveDate as the row identifier.
• Non-historical tables: include id as the row identifier.
• Previously, both fields were always returned, with null values when not applicable.

Why this matters

• Consistency: Aligns with other webhook events that return context-specific data.
• Clearer contract: Payload structure reflects how entries are actually identified.
• Simpler handling: No need to handle null values for irrelevant identifiers.
• More robust parsing: Encourages handling payloads based on table type, not field presence.

Examples

Historical table (e.g. lifecycle, work)

  "companyId": 636192,
  "type": "table.entry.created",
  "triggeredBy": "3332883804594373380",
  "triggeredAt": "2025-01-08T13:06:26.915906",
  "version": "v2",
  "data": {
    "employeeId": "3332883854254932743",
    "tableId": "lifecycle",
    "effectiveDate": "2025-01-08"
  }
}

Non-historical table (e.g. bank accounts, custom table)

{
  "companyId": 636192,
  "type": "table.entry.created",
  "triggeredBy": "3332883804594373380",
  "triggeredAt": "2025-01-08T13:54:03.608759",
  "version": "v2",
  "data": {
    "employeeId": "3332883904477528858",
    "tableId": "bankAccounts",
    "id": 6236350
  }
}

Action required

🚧

Check your code compatibility

• No action required if your integration already handles identifiers based on table type.
• Update your logic if you assumed both id and effectiveDate are always present:
  • Do not rely on null values.
  • Use the table type to determine which identifier to expect.

Learn more

See schema and examples in:

• Table entry created webhook event
• Table entry updated webhook event