Event types and envelope

Event catalog

Event type	Subject	Sent when
person.created	people	A person is created.
person.updated	people	A meaningful field in a person’s webhook snapshot changes.
person.merged	person-mergers	A person merge finishes.
cell.created	groups	A group whose group-type is cell is created.
cell.updated	groups	A meaningful field in a cell’s webhook snapshot changes.
coaching-group.created	groups	A group whose group-type is coaching is created.
coaching-group.updated	groups	A meaningful field in a coaching group’s webhook snapshot changes.
cell-meeting.created	group-events	A group event whose exact internal type is a cell meeting is created.
cell-meeting.updated	group-events	A meaningful field in a cell meeting’s webhook snapshot changes.

Creation events do not have changed-fields. Update events are emitted only when a contracted attribute or relationship changes and include the corresponding field names.

The live catalog is available to full administrators:

GET /v1/webhook-event-types HTTP/1.1
Host: api.celula.in
Authorization: Bearer YOUR_ACCESS_TOKEN
Accept: application/vnd.api+json

{
  "data": [
    {
      "type": "webhook-event-types",
      "id": "person.created",
      "attributes": { "schema-version": 1 }
    }
  ]
}

Event envelope

Every production event is a JSON:API document. This abbreviated person.updated example shows the common structure:

{
  "jsonapi": { "version": "1.0" },
  "data": {
    "type": "webhook-events",
    "id": "66a000000000000000000001",
    "attributes": {
      "event-type": "person.updated",
      "schema-version": 1,
      "occurred-at": "2026-08-16T15:00:00.000Z",
      "operation-id": "person-update:5f3d...:66c...",
      "source": "api",
      "actor": {
        "type": "person",
        "id": "66c000000000000000000001"
      },
      "request-id": "request-correlation-id",
      "changed-fields": ["name", "churchCampus"]
    },
    "relationships": {
      "subject": {
        "data": {
          "type": "people",
          "id": "66d000000000000000000001"
        }
      }
    }
  },
  "included": [
    {
      "type": "people",
      "id": "66d000000000000000000001",
      "attributes": {
        "name": "Ana Example",
        "email": "ana@example.com",
        "is-active": true
      },
      "relationships": {
        "church-campus": {
          "data": {
            "type": "church-campuses",
            "id": "66e000000000000000000001"
          }
        }
      }
    }
  ],
  "meta": {
    "delivery-id": "66b000000000000000000001",
    "delivery-kind": "production",
    "attempt": 1
  }
}

Common fields

Field	Description
data.id	Stable event ID. It is also sent as Webhook-Id and remains the same across retries and manual redelivery.
event-type	Catalog value that identifies what happened.
schema-version	Version of this event type’s payload contract. See the evolution rules below.
occurred-at	ISO 8601 UTC time when the domain change occurred.
operation-id	Server-generated identifier for the logical operation. Multiple related subject events can share its logical component.
source	Origin of the change: api, import, or job.
actor	{ "type": "person", "id": "..." } when a person initiated the operation, otherwise { "type": "system" }.
request-id	Request correlation identifier when available. It is diagnostic metadata, not an idempotency key.
changed-fields	Present on update events. Field identifiers can be camelCase or dotted paths, matching the contracted source field names.
truncation	Present when a to-many relationship was capped.
relationships.subject	JSON:API identifier for the affected resource.
included	Immutable snapshot captured for this event. It is not a live fetch of the resource.
meta.delivery-id	ID for this delivery. It changes when a failed event is manually redelivered.
meta.delivery-kind	production or manual-redelivery for event requests.
meta.attempt	One-based attempt number for this delivery.

Do not assume that an update event contains only changed values. included contains the contracted snapshot after the change; use changed-fields when you need to know what triggered the event.

Schema evolution

All current event types use schema version 1. Non-breaking, additive fields can be introduced without changing that version. Consumers must ignore object members they do not recognize and must not reject a delivery only because its envelope, attributes, relationships, included resources, or metadata contain additional fields.

Removing a field, changing its type or meaning, or otherwise making a breaking payload change requires a new schema-version. Branch on the version when behavior differs, and treat a version your integration does not support as an unsupported contract rather than attempting to process it with version-specific assumptions.

See Payload reference for every contracted subject attribute and relationship.