Short version: treat Job Activity webhooks as field-change notifications, not lifecycle events. ServiceM8 sends a webhook when one of the subscribed fields on an object changes, and the payload contains the affected record UUID and changed fields rather than the full object values. You’ll need to retrieve the record from resource_url or the REST API to read the current values.
entry[0].uuid is the UUID of the JobActivity record that changed, not a create event flag. If uuid appears in changed_fields, we wouldn’t rely on that alone as a guaranteed “created” signal, because the webhook payload is change metadata and doesn’t include a separate create/update/delete event type.
active is the record active/deleted flag, and deleting a Job Activity sets active to 0 while inactive records remain accessible via the API. If you receive an active change, fetch the JobActivity and check the current active value. If you need to distinguish newly created vs restored vs updated records, compare the webhook’s UUID and current values against the state you’ve already stored.
staff_uuid is the staff member assigned to the JobActivity. The JobActivity schema notes that viewed/opened state resets if the staff member or start time is changed, so your integration should handle a staff_uuid change on an existing record. That said, scheduled bookings can also be superseded, so the safer sync pattern is to treat active scheduled JobActivity records as current and treat old inactive records as cancelled or superseded, rather than assuming every reassignment will keep the same JobActivity UUID.
The webhook overview has the key payload details here: Overview