Bevy sends webhook payloads whenever a record of a supported type is created, updated, or in some cases soft-deleted. The sections below describe, for each record type, exactly which actions trigger a payload and what to look for in the data.

Chapter Member — chaptermember

A payload is sent when a chapter member record is created or updated.

• User joins a chapter — A new chaptermember record is created. created_date is populated.
• User leaves a chapter — The chaptermember record is updated. departure_date is populated.

Note: Chapter membership changes are only sent if the "Send chapter member updates" trigger is enabled in your Webhook settings. These changes will not appear in the user webhook, even if the underlying user record is involved.

Chapter — chapter

A payload is sent when a chapter record is created or updated.

• A new chapter is created — A chapter record is created.
• Chapter details change — The chapter record is updated. This includes changes to the name, description, location, timezone, or any other chapter fields.
• A chapter team member is added or changed — The chapter record is updated. Team membership is embedded in the chapter_team array within the chapter payload — there is no separate payload type for chapter team changes.

Event — event

A payload is sent when an event record is created or updated. This includes all status transitions and event completion.

• A new event is created — An event record is created, typically with status: Draft.
• Event details change — The event record is updated. This includes changes to the title, dates, venue, description, or visibility.
• An event is published or canceled — The event record is updated. Check the status field: Draft, Published, or Canceled.
• An event concludes — The event record is updated once the end date passes while status remains Published.

Tip: Filter programmatically using the status field values: Draft, Published, Canceled.

Note: Changes in the calculated values of the events (like total_attendees or checkin_count) doesn't trigger a resync of the event.

Attendee — attendee

A payload is sent when an attendee record is created or updated. This covers registration, check-in, and cancellation.

• User registers for an event — An attendee record is created. status is set to registered.
• User's registration details change — The attendee record is updated.
• User is checked in — The attendee record is updated. status changes to checked-in and checkin_date is populated.
• User cancels their registration — The attendee record is updated. status changes to deleted and deleted_date is populated. The record itself is not removed.

Note: Cancellations are represented as an update, not a deletion. Always check status and deleted_date to identify canceled registrations.

Event Survey Entry — eventsurveyentry

A payload is sent when a survey entry record is created. Survey entries are never updated after submission. Use the survey_type field to identify which survey was completed.

• User completes the pre-order form during registration — survey_type: pre_order. Note that this generates a separate eventsurveyentry record distinct from the attendee record created at the same time.
• User completes the post-event survey — survey_type: post_event.
• A chapter team member completes the post-event survey on behalf of the team — survey_type: post_event_team.

Event People — person

A payload is sent when a key person record is created or updated. Key people are individuals associated with one or more events — such as speakers — managed through the event dashboard.

• A new key person is added to an event — A person record is created.
• A key person's details are updated — The person record is updated. This includes changes to name, company, title, bio, photo, or social handles.

User — user

A payload is sent when a user record is created, updated, or soft-deleted.

• A new user signs up — A user record is created. date_joined is populated.
• A user is added as a Prospective User — A user record is created. A Prospective User is a user created on someone else's behalf — for example, when manually adding an attendee or importing chapter members with an email that doesn't yet exist in the system. They have not registered or logged in themselves.
• User profile data changes — The user record is updated. This covers any field-level change such as name, email, company, or role.
• A user is removed — The user record is updated with a populated deleted_date. The record is not permanently deleted — it is soft-deleted and remains accessible with deleted_date set.

Note: There is no hard-delete for user records. To detect removed users, check for a non-null deleted_date value.

Note: When the last_login field in the User object is updated, the webhook payload is not sent. That means each the user record is not sent every time the user login.

Note: Changes to a user's chapter memberships do not trigger the user webhook. To receive those updates, enable the "Send chapter member updates" trigger in your Webhook settings.

Quick Reference

• chaptermember — Created, updated
• chapter — Created, updated (including team changes)
• event — Created, updated (including status changes and conclusion)
• attendee — Created, updated (including check-in and cancellation)
• eventsurveyentry — Created only
• person — Created, updated
• user — Created, updated, soft-deleted