What this endpoint is for
The engine auto-assembles one canonical decision context per Recommend call (customer.*, <entity>.*, behavior.*, journey.*, attributes.*). This endpoint answers the authoring-time question “what keys can I reference?” — it returns the full key catalog derived from your tenant’s metadata (customer schema columns, active Schema Joins and their aggregations, active Behavioral Metrics), without assembling any real customer.
It powers the attribute picker in the Decisioning Gates builder (Studio → Decisioning Gates), so authors pick verified keys instead of typing a guess — eliminating the namespace-mismatch class of silently skipped gates at author time.
GET /api/v1/decision-context/preview
Tenant-scoped, read-only. Any role (viewer+).Query Parameters
Response
A JSON array of key descriptors:How the catalog is built
customer.*— every live column of eachentityType: customerschema’sds_*table (the same column universe the runtimeSELECT *s), minus the internalid/created_at/updated_atcolumns.<entity>.*— for each active Schema Join withautoEnrich: true: the join’s configuredaggregationsproduce exactly one key each (alias, else<field>_<aggregator>; count-star →count). A join with no aggregations shows the default rollup:<entity>.countplus the first row’s scalar fields. Every join also advertises the raw-collection escape hatch<entity>[].behavior.*— one key per active Behavioral Metric, slugified exactly like the runtime (metric “Converts 30d” →behavior.converts_30d).journey.*—journey.current,journey.step,journey.enrolled(all absent at runtime when the customer isn’t enrolled).attributes.*— request-time attributes are free-form, so the catalog documents the wildcard plusattributes.propensityScores(read bypropensity_thresholdgates).
The catalog lists keys that can exist at decision time. A key may still be absent for a specific customer (e.g.
journey.current when not enrolled, a join that matched zero rows) — attribute-reading gates then follow their onMissing behavior.