Skip to main content
Grow CRM emits webhook events across the full product lifecycle. Your endpoint may receive six event keys: item.created, item.updated, item.deleted, item.sundry, item.activity, and item.imported. Every event key uses the item.* prefix — you will see item.created, item.updated, and so on rather than product.*. Use item.created for single product creation, item.updated for form edits, item.activity to track task template changes, and item.imported for bulk imports — note that imported products do not also fire item.created, so you must subscribe to both events if you need to capture all new products regardless of how they were added.
The webhook envelope structure, delivery behaviour, and retry logic are documented in Introduction. Signature verification is covered in Verification. Those conventions apply to every event on this page and are not repeated here.

The product object

Every event key except item.deleted and item.imported carries the full product object. In item.created the object appears flat inside data; in item.updated and item.sundry it is nested under data.item.
The dates.created timestamp on product objects is a raw database value in Y-m-d H:i:s format (for example "2026-07-31 09:00:00"), not the ISO 8601 with microseconds format you see on invoices, payments, and expenses.

item.created

Fires when a product is created. data is the full product object.

item.updated

Fires when a significant change is made to a product. Read data.change to determine what changed; data.item contains the full product object.

item.sundry

Fires when a minor or cosmetic field is edited. Read data.field to determine which field changed; data.item contains the full product object.
Changing the category of several products at once delivers one item.sundry event per product — not one event containing a list.

item.activity

Fires when a child record on the product changes. Products produce only type: "task" — these are the task templates attached to a product, which Grow CRM copies onto a project when the product is used. Read data.action to distinguish additions, edits, and deletions.

item.deleted

Fires after the product is permanently deleted. Because the record no longer exists, data contains only the product id. Both delete paths are covered: the checkbox selection on the products list, and the bulk delete action. Deleting several products at once delivers one event per product — not one event containing a list.

item.imported

Fires when a bulk product import finishes. Imported products do not also fire item.created — subscribe to item.imported in addition to item.created if you need to capture all new products regardless of how they entered the system.
Bulk-imported products fire only item.imported, not item.created. If you subscribe to item.created alone, you will miss products added via the import flow.
Each record in data.records carries a condensed shape — not the full product object: The data envelope for item.imported follows the standard import batch shape. The top-level id in the envelope is the import_ref string, not a numeric resource id.