Tasks

New to webhooks? Start with Getting started (envelope, delivery, retries) and Verification (confirming a request came from Grow CRM). Those conventions apply to every event below and are not repeated here.

Tasks expose all five keys: task.created, task.updated, task.deleted, task.sundry, task.activity.

The task object

Every key except .deleted carries this shape, either flat (.created) or nested under task (.updated/.sundry):

{
  "id": 512,
  "title": "Build homepage wireframe",
  "description": "First-pass layout for review.",
  "status": { "id": 2, "title": "In Progress", "color": "info" },
  "priority": { "id": 2, "title": "High" },
  "active_state": "active",
  "billable": "yes",
  "project": { "id": 305, "title": "Website Redesign" },
  "client": { "id": 12, "name": "Acme Inc" },
  "dates": {
    "start": "2026-07-16",
    "due": "2026-07-20",
    "created": "2026-07-16T08:00:00.000000Z",
    "updated": "2026-07-16T08:12:00.000000Z"
  },
  "assigned": [ { "id": 34, "name": "John Smith" } ],
  "tags": ["design"]
}

Field	Type	Notes
`id`	integer	`task_id`.
`title`	string
`description`	string\|null
`status`	object	`{ id, title, color }`.
`priority`	object	`{ id, title }` — `title` is `null` if no priority is set.
`active_state`	string	`active` or `archived`.
`billable`	string	`yes` or `no`.
`project`	object	`{ id, title }`.
`client`	object	`{ id, name }`.
`dates`	object	`start`, `due` are raw dates (date only); `created`, `updated` are ISO 8601 with microseconds (`Task` recasts these via `CREATED_AT`/`UPDATED_AT`).
`assigned`	array	`[{ id, name }]`, one per assigned user.
`tags`	array of strings

`task.created`

Fires when a task is created, including via clone. data is the full task object above.

{
  "event": "task.created",
  "id": 512,
  "created": "2026-07-16T08:00:00+00:00",
  "data": {
    "id": 512,
    "title": "Build homepage wireframe",
    "description": null,
    "status": { "id": 1, "title": "Not Started", "color": "default" },
    "priority": { "id": null, "title": null },
    "active_state": "active",
    "billable": "no",
    "project": { "id": 305, "title": "Website Redesign" },
    "client": { "id": 12, "name": "Acme Inc" },
    "dates": { "start": null, "due": null, "created": "2026-07-16T08:00:00.000000Z", "updated": "2026-07-16T08:00:00.000000Z" },
    "assigned": [],
    "tags": []
  }
}

`task.updated`

Fires on a significant change. data.change tells you which; data.task is the full object. There is no edited change for tasks — core has no single “task edited” event; edits are always field-specific and land under one of the changes below (or under .sundry, for the minor ones).

`change`	Fires when
`status`	The task’s status changes (including a status toggle).
`priority`	The task’s priority changes.
`assigned`	The task’s assigned user(s) change.
`recurring`	The task’s recurring settings are updated or stopped.
`active_state`	The task is archived or restored.

{
  "event": "task.updated",
  "id": 512,
  "created": "2026-07-16T08:05:00+00:00",
  "data": {
    "change": "status",
    "task": { "id": 512, "status": { "id": 3, "title": "Complete", "color": "success" }, "...": "..." }
  }
}

`task.sundry`

Fires on a minor, cosmetic field edit. data.field names it; data.task is the full object (same shape as .updated, just a lower-significance discriminator).

`field`	Fires when
`tags`	The task’s tags are changed.
`custom_fields`	One or more custom field values are updated.

{
  "event": "task.sundry",
  "id": 512,
  "created": "2026-07-16T08:07:00+00:00",
  "data": {
    "field": "tags",
    "task": { "id": 512, "tags": ["design", "urgent"], "...": "..." }
  }
}

`task.activity`

Fires when a child record on the task changes.

`type`	`action`	Item shape
`comment`	`added`, `deleted`	`{ id, text, author, created }` — `author` is the commenter’s first name only.
`attachment`	`added`	`{ id, uniqueid, filename, created }`
`attachment`	`deleted`	`{ id }` only — the attachment record is already gone by the time this fires.
`checklist`	`added`, `updated`, `deleted`, `status_changed`	`{ id, text, status, created }` — `status_changed` fires when an item is ticked or un-ticked; `status` is `pending` or `completed`.
`checklist_comment`	`added`, `deleted`	`{ id, checklist_id, text, author, created }` — kept separate from `comment` so a note on a checklist item is not mistaken for a comment on the task.

Reordering checklist items does not fire an event, and importing a checklist fires nothing per item.

{
  "event": "task.activity",
  "id": 512,
  "created": "2026-07-16T08:10:00+00:00",
  "data": {
    "type": "comment",
    "action": "added",
    "item": { "id": 5012, "text": "Looks good, shipping today.", "author": "Jane", "created": "2026-07-16T08:10:00.000000Z" }
  }
}

`task.deleted`

Fires after the task is deleted. data is just the id — the record no longer exists to describe.

{
  "event": "task.deleted",
  "id": 512,
  "created": "2026-07-16T08:15:00+00:00",
  "data": { "id": 512 }
}

Getting Started

Clients

Sales

Billing

Projects & Work

Support

Organisation

Tasks

Tasks

The task object

`task.created`

`task.updated`

`task.sundry`

`task.activity`

`task.deleted`

​Tasks

​The task object

​task.created

​task.updated

​task.sundry

​task.activity

​task.deleted

Tasks

The task object

`task.created`

`task.updated`

`task.sundry`

`task.activity`

`task.deleted`