Skip to main content
Zolt emits a webhook event every time a significant action occurs on a resource in your workspace. This page lists every available event type, grouped by resource, along with an example payload so you know exactly what your endpoint will receive. Subscribe only to the events your integration actually needs — narrowing your subscription reduces noise and keeps your handler lean.
All event names follow the resource.action pattern. The first segment identifies the resource type (task, project, member) and the second segment describes what happened (created, updated, deleted, and so on). This consistent naming convention makes it straightforward to route incoming events with a single switch or match statement in your handler.

Task Events

Fired immediately after a task is created in any project within your workspace. The data.task object contains the full task record at the moment of creation.
task.created payload
Fired when any editable field on a task is modified — such as its title, description, priority, assignee, or due date. The payload includes a changes object that shows the previous and new value for every field that was modified, making it easy to react only to the specific changes your integration cares about.
task.updated payload
Fired when a task is hard-deleted from a project. Because the task no longer exists at delivery time, the payload captures the task’s last known state so you can clean up any references to it in your system.
task.deleted payload
Fired specifically when a task’s status column changes (for example, from todo to in_progress, or from in_progress to done). While task.updated also fires in these cases, task.status_changed provides a cleaner subscription point if your integration only cares about workflow progression — such as triggering a CI pipeline when a task moves to in_review.
task.status_changed payload

Project Events

Fired when a workspace member creates a new project. The payload includes the project’s initial configuration, including its name, description, and visibility setting.
project.created payload
Fired when a project’s name, description, visibility, or other settings are edited. Like task.updated, the payload includes a changes object with before and after values for each modified field.
project.updated payload
Fired when a project is archived. Archived projects are read-only and hidden from the active project list. Your integration may use this event to lock downstream resources or notify stakeholders.
project.archived payload
Fired when a project is hard-deleted, along with all its tasks and associated data. Use this event to remove references to the project from any external systems that were syncing with it.
project.deleted payload

Member Events

Fired when a workspace admin sends an invitation to a new member. The invitation may still be pending acceptance at the time this event fires — subscribe to member.joined if you only need to act once the user has accepted.
member.invited payload
Fired when an invited user completes sign-up and joins the workspace. At this point the member has an active account and can be assigned tasks. The payload includes their new user ID, which you can use to link records in your external system.
member.joined payload
Fired when a member is removed by an admin or leaves the workspace voluntarily. After this event, the member loses access to all workspace resources. Use this event to revoke any delegated permissions your integration may have granted based on their membership.
member.removed payload
Dernière modification le 18 septembre 2026