Activity Generation Configs

Overview

An Activity Generation Config (AGC) describes how the platform derives a user's retention lifecycle state from raw activity data. It is a lifecycle-only configuration: base metadata, an optional audience, and exactly three required lifecycle pillars.

Every AGC belongs to one project: the endpoints work on the AGCs of the active project, and an AGC of another project responds 404 as if it did not exist. Its name is unique within the project.

The three pillars are 1:1 with the AGC: every AGC always has exactly one activationConfig, one engagementConfig, and one resurrectionConfig. You cannot create an AGC with a missing pillar, and you cannot create a pillar that is not attached to an AGC.

Status

Every AGC has a status:

The status changes only through two actions, both with the activity-generation-config:update permission:

• Publish — draft or paused → active.
• Pause — active → paused.

status is not accepted in any create or update body. Only active configurations are meant to run: list them with GET /api/activity-generation-configs?status=active.

Effective audience

audienceId is the AGC's own audience, and it is optional. Reads — GET /:id and the list — also return effectiveAudienceId, the audience the AGC runs over:

• audienceId, when the AGC has its own audience;
• otherwise, the project's root audience (see Projects → Root audience).

effectiveAudienceId is never null. It is computed when the AGC is read: it is not stored, and it is not sent in any body.

Config hashes

GET /:id returns a configHashes object — a deterministic per-pillar hash (16 hexadecimal characters) for each of the three pillars:

{
  "activation": "9f1c2a3b4d5e6f70",
  "engagement": "a1b2c3d4e5f60718",
  "resurrection": "0f1e2d3c4b5a6978"
}

Callers use these hashes to cheaply detect when a pillar's configuration has changed without diffing the full nested payload. The hash is computed over the pillar's semantic content only: volatile fields (id, timestamps) are stripped, and child collections are hashed order-independently, so reordering children without changing their values does not change the hash.

Authentication

All endpoints require a JWT Bearer token, the x-tenant-id header identifying the tenant whose schema the request operates on, and the x-project-id header identifying the project the request works in (see Authentication → Project Context).

-H "Authorization: Bearer <token>"
-H "x-tenant-id: <tenant-id>"
-H "x-project-id: <project-id>"

Permissions

Endpoints