Skip to main content
See also: Decision Flows concept and configuration for what this API powers, when to call it, and how it is configured.
Decision Flows list view in the Kaireon Studio

The Decision Flows page.

Decision Flows are the heart of KaireonAI’s decisioning engine. Each flow defines a composable pipeline of nodes (enrichment, qualification, scoring, ranking, filtering) that selects and ranks Offers for a given customer context.
See the Decision Flows feature page and Composable Pipeline reference for UI guidance and architecture details.

Base path


List Decision Flows

Returns a paginated list of Decision Flows, ordered by status then by last update (newest first).

Query parameters

If the tenant has zero Decision Flows, this endpoint lazily auto-creates a base flow and returns it, so the list is never empty for an active tenant.

Response 200


Get a single Decision Flow

Returns one Decision Flow by ID for the authenticated tenant. Soft-deleted flows return 404.

Path parameters

Response 200

Error codes

Roles

admin, editor, viewer.

Create a Decision Flow

Creates a new Decision Flow with a default draft configuration.

Request body

isDefault is not a settable request field on create — it is stripped by the validation schema. The first flow created in a tenant is automatically marked default; subsequent flows are created with isDefault: false.

Example request

Response 201

Returns the created Decision Flow. The draftConfig is populated with the default stage configuration and publishedVersions starts as an empty array.

Error codes


Update a Decision Flow

Updates an existing Decision Flow. When draftConfig is provided, it is validated against the pipeline schema and goes through the pipeline validator for structural correctness.

Request body

Always send rowVersion when updating draftConfig to prevent overwriting concurrent edits. On conflict, the API returns 409 with a message to refresh and retry.

Flow config v2 schema

The draftConfig must conform to the flow config v2 schema:
  • version: Must be 2.
  • nodes: Array of pipeline nodes (minimum 2). Each node has id, type, and config.
  • flowConfig: Optional flow-level configuration.

Pipeline node types

16 node types organized across 3 phases:
rank and group are mutually exclusive. A flow may contain a rank node (single-placement top-N selection) or a group node (multi-placement allocation across zones), but not both — rank throttles group’s input and leaves placements unfilled. A draftConfig containing both fails structural validation with RANK_AND_GROUP_CONFLICT and the create/update request is rejected with 422.

Score node methods

The Score node uses the PRIE formula (Propensity x Relevance x Impact x Emphasis). Scoring methods include:
  • priority_weighted — Uses offer priority and business value
  • propensity — Uses a scoring model for the P factor
  • formula — Custom formula-based scoring

Rank node methods

Compute node

Supports formulaExtras for adding personalized computed values to the response. Each extra defines a key, formula, and outputType that are evaluated per candidate at decision time.

Example request

Response 200

Returns the updated Decision Flow. The rowVersion is incremented.

Error codes


Delete a Decision Flow

Soft-deletes a Decision Flow by ID. The record is marked as deleted but retained in the database for audit purposes.

Query parameters

Response 200

The cascaded field indicates how many related records (if any) were also soft-deleted.
This endpoint uses soft-delete — the record is not physically removed. It is excluded from GET results by default. To include soft-deleted records, pass ?includeDeleted=true on the GET request.

Error codes


Publish a Decision Flow

Snapshots the current draftConfig as a new published version. The flow status is set to active. A scoring method must be configured before publishing.

Request body

Example request

Response 200

Returns the updated Decision Flow with the new version appended to publishedVersions.

Four-eyes publish approval (opt-in)

When the tenant setting requirePublishApproval is true, publish is gated: the flow must have a fresh, approved ApprovalRequest with entityType: "decisionFlow", action: "publish", and entityId equal to the flow’s id. Because approval-stage walking already rejects self-approval and duplicate approvers, an approved request implies two distinct identities. One approval authorizes exactly one publish: the successful publish stamps the approval’s approvalId onto the publishedVersions[] entry it creates, so a second publish on the same approval is rejected as consumed. The next publish needs a new approval. The gate fails closed — if the tenant-settings lookup errors, publish is blocked unless a valid approval already exists. The default (requirePublishApproval: false) keeps one-click publish for existing tenants. A blocked publish returns 422 and writes a publish_blocked audit entry:
reason is "no_approval" (no fresh approved request) or "consumed" (the most recent approval was already used by a previous publish). The audit reason is publish_approval_missing or publish_approval_consumed respectively.

Error codes


Role requirements


Optimistic concurrency

Decision Flows support optimistic concurrency control via the rowVersion field. When updating a flow:
  1. Read the current rowVersion from the GET response.
  2. Include rowVersion in your PUT request body.
  3. If the server’s rowVersion does not match, the update is rejected with 409 Conflict and a message to refresh and retry.
  4. On successful update, the rowVersion is automatically incremented.
This prevents concurrent editors from overwriting each other’s changes.

Soft-delete and audit

Decision Flows use soft-delete with audit snapshots. When a flow is deleted:
  1. The deletedAt timestamp is set (record is retained).
  2. An audit snapshot is captured with the full state before deletion.
Updates also create audit snapshots via auditedUpdate, incrementing the rowVersion on each change. The first flow created in a tenant is automatically marked as the default (isDefault: true). To include soft-deleted flows in GET responses, add ?includeDeleted=true to the query string.

Decision Flows

Learn more about building Decision Flows in the platform UI.