Lifecycle Config
Read-only access to the three lifecycle pillars of an Activity Generation Config.
Overview
A lifecycle config is one of the three pillars that make up an Activity Generation Config (AGC). Each pillar classifies a different stage of a customer's retention lifecycle:
| Pillar | Resource | Purpose |
|---|---|---|
activation | Activation Configs | Classifies whether (and how strongly) a user has activated, based on early action moments. |
engagement | Engagement Configs | Buckets active users into engagement levels (e.g. casual, core, power). |
resurrection | Resurrection Configs | Detects users decaying into inactivity and classifies recovery vs. churn. |
Every lifecycle config row always belongs to exactly one AGC (activityGenerationConfigId is NOT NULL, 1:1). There is no such thing as a standalone, orphaned pillar.
These resources are read-only. There is no standalone create, edit, or delete: only GET (list) and GET /:id exist. A lifecycle config is created and edited exclusively through the AGC flow — there are no templates, no clone, and no sourceConfigId/usageType.
How lifecycle configs are created and edited
You never create or mutate a pillar directly. Instead, the pillars are written through the AGC endpoints:
Create an AGC
Creates the AGC together with all three lifecycle pillars in one transactional request.
Update lifecycle pillars
In-place replacement of one or more pillars on an existing AGC.
To prefill the AGC creation wizard with sensible starting values, fetch the platform defaults from GET /api/lifecycle-defaults.
Authentication
All endpoints require a JWT Bearer token plus the x-tenant-id header identifying the tenant whose schema the request operates on. The three pillar endpoints (activation, engagement and resurrection configs) also require the x-project-id header, which identifies the project the request works in (see Authentication → Project Context); GET /api/lifecycle-defaults ignores it.
-H "Authorization: Bearer <token>"
-H "x-tenant-id: <tenant-id>"
-H "x-project-id: <project-id>"Permissions
| Permission | Grants |
|---|---|
lifecycle-config:view | List and read the three pillars (activation / engagement / resurrection). |
activity-generation-config:view | Read the lifecycle defaults prefill payload. |
Serialization convention: the three pillar GET responses are camelCase (e.g. sourceTable, userRetentionStatusConfigId). The exception is GET /api/lifecycle-defaults, whose response is snake_case — it is a hardcoded platform-defaults payload, not an entity.