Event catalog

When you create a webhook, you choose which events it receives. This page lists every available event, explains when each one is sent and describes the message format.

Message format

Every message has the same envelope. Only the type and the content of data change from one event to another.

{
  "uuid": "6c1f0f8e-4f5b-4a53-9d0e-2b7c9a1e3f42",
  "organizationsUuid": "0d5a7e3c-8b1f-4c2e-a6d9-5f4e3b2a1c0d",
  "timestamp": "2026-10-13T14:32:05.123Z",
  "type": "group_assignment.created",
  "data": {
    "groupAssignmentsUuid": "f1e2d3c4-b5a6-4978-8695-a4b3c2d1e0f9",
    "groupsUuid": "9a8b7c6d-5e4f-4321-9876-0fedcba98765"
  }
}

Field	Description
uuid	Unique identifier of the event. It is the same value as the webhook-id header and never changes between retries. Store it to detect duplicates.
organizationsUuid	The organization where the event happened. Check it before processing the message.
timestamp	When the event happened, in ISO 8601 format and UTC. It does not change between retries.
type	The event type, in the form resource.action, for example membership.created. See the list of events.
data	The identifiers of the resources involved. The fields depend on the event type.

Only identifiers, never full details

Messages deliberately carry only identifiers, never names, e-mail addresses or other attributes. When your system needs more information, it reads it from the BreezeAuth API using these identifiers. This approach:

• keeps personal data out of messages, logs and queues;
• ensures your system always acts on the current state, even if messages arrive late, more than once or out of order;
• keeps messages small and stable when new attributes are added to the product.

When an event involves a resource that lives inside another one, data also includes the identifier of the parent resource. For example, an application assignment comes with the identifier of its application, because both are needed to read the assignment from the API.

Available events

Event names in the Events field of the admin console are shown as readable labels, such as Membership created. In messages, the type field uses the technical name, such as membership.created.

Memberships (users)

A membership is a user’s link to your organization. See IAM concepts.

Event	Sent when	data fields
membership.created	A user joins the organization (invited, provisioned or created).	membershipsUuid
membership.updated	A user’s profile, role or status changes, such as a suspension.	membershipsUuid
membership.deleted	A user is removed from the organization.	membershipsUuid

Groups

Event	Sent when	data fields
group.created	A group is created.	groupsUuid
group.updated	A group’s details, such as its name, change.	groupsUuid
group.deleted	A group is deleted.	groupsUuid

When a group is deleted, its application assignments are removed with it, and no separate application_assignment.deleted events are sent for them. Treat group.deleted as the end of any application access granted through that group.

Group assignments

A group assignment makes a user, or another group, a member of a group. See Group members.

Event	Sent when	data fields
group_assignment.created	A member is added to a group.	groupAssignmentsUuid, groupsUuid
group_assignment.deleted	A member is removed from a group.	groupAssignmentsUuid, groupsUuid

groupsUuid identifies the group that gained or lost the member.

With nested groups, events are also sent for indirect memberships: adding the group “Backend” to “Engineering” sends one group_assignment.created event for “Backend” and one for each of its members who becomes a member of “Engineering”. No event is sent when an existing membership only changes between direct and indirect.

Applications

Event	Sent when	data fields
application.created	An application is registered in the organization.	applicationsUuid
application.updated	An application’s configuration changes.	applicationsUuid
application.deleted	An application is removed.	applicationsUuid

Application assignments

An application assignment gives a user or a group access to an application.

Event	Sent when	data fields
application_assignment.created	A user or group is given access to an application.	applicationAssignmentsUuid, applicationsUuid
application_assignment.updated	An assignment changes, for example its roles or attributes.	applicationAssignmentsUuid, applicationsUuid
application_assignment.deleted	A user’s or group’s access to an application is removed.	applicationAssignmentsUuid, applicationsUuid

Domains

Event	Sent when	data fields
domain.created	A domain is added to the organization.	domainsUuid
domain.updated	A domain changes, for example when its verification completes.	domainsUuid
domain.deleted	A domain is removed.	domainsUuid

About update events

*.updated events are sent only when something meaningful changes. Internal bookkeeping, such as a change to a record’s modification date alone, does not produce an event.

An update message does not say which fields changed. If your system needs to react to a specific change, such as a user’s department, keep a copy of the values it cares about and compare them with the current data from the API.

Choosing events

Subscribe only to the events the receiving system actually uses. Fewer events mean less traffic for your endpoint and a clearer event history. Your endpoint should still respond with 2xx to any event type it does not recognize, because new event types may be added in the future and you may subscribe to them later.