Event types

Webhooks and the event feed use the same events. Each event says that one record changed: which record, its new revision and the names of the fields that changed.

Event types

There are three kinds of event for each record family: created, updated and deleted.

Resource family	Event types
customers	customer.created, customer.updated, customer.deleted
customer_locations	customer_location.created, customer_location.updated, customer_location.deleted
jobs	job.created, job.updated, job.deleted
members	member.created, member.updated, member.deleted

You receive events only for families your webhook or feed request includes, that FieldTask has enabled and enrolled for your organization, and that the connection can read. Quotes, invoices, products, job items, member invitations and timesheets have no events.

Kind	Meaning
created	The record became visible through the API: it was created, or a deleted record was restored. changed_fields lists all of its fields.
updated	One or more of the record's fields changed. changed_fields names them.
deleted	The record was deleted or is no longer visible through the API. tombstone is true and changed_fields is empty.

The event object

A webhook request body is one event. A feed page has a list of them in data.

A job.updated event

{
  "event_id": "eeeeeeee-eeee-4eee-8eee-eeeeeeeeee02",
  "schema_version": 1,
  "event_type": "job.updated",
  "observed_at": "2026-11-03T14:19:58.112Z",
  "published_at": "2026-11-03T14:19:59.004Z",
  "resource": {
    "type": "jobs",
    "id": "66666666-6666-4666-8666-666666666666",
    "revision": 3
  },
  "changed_fields": ["schedule", "status", "updated_at"],
  "tombstone": false
}

Field	Meaning
event_id	Unique ID of this event. Retries and replays of a webhook reuse it, and it's also sent as the webhook-id header.
schema_version	Always 1 in this version.
event_type	One of the event types above.
resource.type	customers, customer_locations, jobs or members.
resource.id	ID of the record that changed.
resource.revision	The record's revision after this change. See Revisions.
changed_fields	Names of the fields that changed, sorted. Only fields this connection can read are listed.
tombstone	true for deleted events, otherwise false.
observed_at	When FieldTask recorded the change, in UTC.
published_at	When the event was made available to webhooks and the feed, in UTC.

The example is formatted for reading. A real webhook body is compact JSON with no spaces, and you must verify its exact bytes before parsing it. Webhook requests also carry the headers webhook-id, webhook-signature, webhook-timestamp.

Field names, not values

Events don't contain record data. changed_fields uses the field names from the record's REST response, such as schedule on a job or primary_address on a customer. To get the new values, read the record:

resource.type	Read it with
customers	GET /public/v1/customers/{id}
customer_locations	GET /public/v1/customer-locations/{id}
jobs	GET /public/v1/jobs/{id}
members	GET /public/v1/members/{id}

The record you read can be newer than the event, because it reflects every change up to now. That's expected.

Deleted records and tombstones

A deleted event is a tombstone: it tells you to remove the record from your copy.

A job.deleted event

{
  "event_id": "eeeeeeee-eeee-4eee-8eee-eeeeeeeeee03",
  "schema_version": 1,
  "event_type": "job.deleted",
  "observed_at": "2026-11-03T14:22:40.517Z",
  "published_at": "2026-11-03T14:22:41.090Z",
  "resource": {
    "type": "jobs",
    "id": "77777777-7777-4777-8777-777777777777",
    "revision": 5
  },
  "changed_fields": [],
  "tombstone": true
}

• Reading a deleted record returns 404. Don't treat that as an error in your sync.
• Deleted events are always sent, even though the record can no longer be read.
• An updated event for a record that has since been deleted is skipped; you get its deleted event instead.
• A record can come back. Restoring it produces a created event with a higher revision.

Ordering

Don't rely on events arriving in the order changes happened.

• The feed returns events in the order FieldTask added them, which is close to the order the changes happened but not exact.
• Webhooks can arrive in any order, because a failed delivery is retried later while newer events are delivered.
• The same event can arrive more than once.

Use revision to decide which state is newer, and event_id to recognize an event you've already processed.

Revisions

Each record has a revision that starts at 1 and increases with every recorded change. It's the same number as the revision field in the record's REST responses. You won't necessarily see every revision, so gaps are normal.

To apply events safely:

1. Keep the latest revision you've stored for each record.
2. If an event's resource.revision is less than or equal to it, ignore the event.
3. Otherwise read the record (or remove it, for a tombstone) and store the revision from what you read.

History

FieldTask keeps events for 30 days. Webhook deliveries can be replayed, and feed cursors can be used, only within that period. After it, rebuild your copy from the list endpoints.