group.updated

project_id is always null for group events.

When this fires

A group is renamed, or the permissions attached to it are replaced.

Who is in the group is a separate event — group.members_synced — because the two changes have different consequences. A rename is cosmetic; changing the permission set silently re-scopes everyone already in the group.

Required ability

group:view — token must carry this at mint time to subscribe an endpoint to this event.

Payload

{
  "id": "evt_01HX...",
  "type": "group.updated",
  "created_at": "2026-05-22T10:05:00Z",
  "api_version": "2026-05-01",
  "project_id": null,
  "data": {
    "team_id": "a83f0d51-4c92-4b7e-8615-2fd9e70a3c86",
    "group_id": "1f68d92a-04c5-4e83-97b1-3d6a05e2f847",
    "code": "core-community",
    "name": "Core Community"
  }
}

Field reference

Field	Type	Notes
`id`	string ULID	Unique event id, prefixed `evt_`. Use for idempotent processing.
`type`	string	Always `group.updated` for this event.
`created_at`	ISO 8601 timestamp	Server-side emission time.
`api_version`	string	Webhook API contract version.
`project_id`	null	Always `null` — account-level event.
`data.team_id`	string UUID	Team that owns the group.
`data.group_id`	string UUID	Group identifier.
`data.code`	string	Stable group code (immutable across renames).
`data.name`	string	Updated display name.

Caveats

The permission set is not in the payload, so this event tells you a group changed without telling you into what. Read GET /v1/groups/{group} for the current permissions.
Permissions replace, they do not merge. An update that sends permissions sets them to exactly that list, so everyone in the group can gain and lose access in the same event.
code is immutable, so a rename never breaks a reference held elsewhere.
Membership is untouched here. See group.members_synced.

group.members_synced — who is in the group changed.
group.created — predecessor.
group.deleted — terminal state.
Group events overview — back to family overview.