Lamba

Event model

Treat webhook payloads as immutable event facts with stable identifiers.

Baseline payload shape

{
  "id": "evt_01J...",
  "type": "session.created",
  "occurredAt": "2026-03-05T10:15:30Z",
  "workspaceId": "wrk_...",
  "projectId": "prj_...",
  "environment": "test",
  "data": {}
}

data contains the raw domain payload for that event type. The public customer contract does not wrap it again under nested event, projectId, or tenantId producer-specific envelopes.

Event groups

user.*
profile.*
membership.*
invitation.*
role.*
session.*
identity.*
security.*
application.*
domain.*
webhook.endpoint.*
campaign.*
sms.*

Current product-facing webhook examples include:

Event	Meaning
`user.login`	A user signed in successfully
`user.logout`	A user ended a session
`user.mfa.enabled`	A user enabled multi-factor authentication
`user.created`	A user was registered
`session.revoked`	A session was revoked
`campaign.sent`	A campaign send completed
`sms.sent`	An SMS notification was delivered

Delivery guarantees

At-least-once delivery
Retries on non-2xx responses
Signed payloads with replay defense

Consumer requirements

Verify signature before parsing.
Deduplicate by event ID.
Process idempotently.
Return 2xx only after durable acceptance.

Operational fields to log

event ID
event type
workspace/project scope
environment
trace or correlation ID
processing outcome
retry count

Growth workflow events

Growth workflows should treat webhook payloads as identity-linked facts. Campaign, notification, loyalty, and analytics consumers should deduplicate by event ID and preserve Project scope so downstream systems do not build a second, inconsistent user graph.

Webhook signature verification: /docs/reference/webhook-signatures
Webhooks quickstart: /docs/quickstart/webhooks
Growth workflows: /docs/growth/overview