- What triggers it in the FPT business model
- The
datapayload shape — the event-specific bit inside the envelope - When you’d care about it
eventId, eventType, eventTimestamp, etc.) see the envelope reference.
Available today (v1.1)
Thecontact.* family — four focused events covering the contact lifecycle. Each one represents a distinct business signal so you can subscribe only to what your integration needs.
contact.created
A new contact was added at a location.
contact.status_changed
Contact moved between lifecycle groups (Lead → Member → etc.).
contact.sub_group_changed
Contact assigned to a different business sub-group.
contact.deleted
A contact was removed or deactivated.
Why no generic
contact.updated? Fit Pro Tracker intentionally does not expose a catch-all “any field changed” event in v1.1. A staff member editing a contact often saves multiple times in quick succession (phone, then notes, then group), and a generic update event would flood your handler with 3-4 near-duplicate events per second. Instead, v1.1 ships focused events that match specific business signals. v1.2 will introduce additional focused events for identity changes (contact.identity_updated), address changes, and activity logging so partners can subscribe by intent rather than by every database write.On the roadmap
These event families are designed and on the schedule but not yet emitted. You can pre-plan your integration around them, but subscribing today won’t deliver anything.contact.* (additional focused events) — v1.2
contact.* (additional focused events) — v1.2
contact.identity_updated (firstName / lastName / email / phone changed),
contact.address_updated (city / state / postal / country changed),
contact.note_added, contact.tag_added, contact.tag_removed. Replace the
catch-all “contact.updated” pattern with discrete, partner-friendly signals.membership.* — v1.2
membership.* — v1.2
membership.started, membership.renewed, membership.cancelled, membership.frozen, membership.expired — emitted from the FPT billing lifecycle.payment.* — v1.2
payment.* — v1.2
payment.succeeded, payment.failed, payment.refunded — emitted when transactions clear the payment gateway.subscription.* — v1.2
subscription.* — v1.2
subscription.created, subscription.updated, subscription.cancelled — for recurring billing plans (distinct from membership lifecycle).appointment.* — v1.3
appointment.* — v1.3
appointment.scheduled, appointment.rescheduled, appointment.completed, appointment.cancelled, appointment.no_show — 1-on-1 appointment lifecycle.class.* — v1.3
class.* — v1.3
class.attended, class.cancelled, class.waitlisted — group class attendance.message.* — v1.3
message.* — v1.3
message.sms_received, message.sms_failed, message.email_received, message.call_received — inbound communications from contacts.task.*, note.*, tag.*, campaign.* — v1.3+
task.*, note.*, tag.*, campaign.* — v1.3+
Staff workflow and automation events.
Naming conventions
- Resource.verb format —
<entity>.<past_tense_action> - Lowercase, dot-separated —
contact.sub_group_changed, neverContactSubGroupChangedorcontact-sub-group-changed - Past tense — events describe things that already happened.
created,updated,deleted. Nevercreatingordelete. - Stable — once we ship an event type, the string never changes. Adding new fields to its
datapayload is forward-compatible; removing fields requires a new event type.