Skip to main content
A catalog is a named set of choices associated with a model. Use catalogs when the same outcomes appear across many requests or services. The decision request then carries a short catalog ID instead of repeating the full array.

​
Catalog fields

​
Catalog lifecycle

  1. Create a catalog with the choices your workflow accepts.
  2. Store the returned ID and version with your application configuration.
  3. Reference the catalog from decision requests.
  4. Read the catalog when you need to display or audit its current definition.
  5. Delete it when the workflow is retired.

​
Why use a catalog?

  • Keep a single source of truth for choices shared by multiple services.
  • Avoid sending a large repeated choice array on every request.
  • Change the catalog deliberately instead of silently changing a caller’s request.
  • Associate the catalog with one model and make that relationship explicit.
Catalogs are private by default. Use visibility: "public" only when the catalog is intentionally shareable in your deployment.

​
Catalog versus inline choices

Use inline choices when the outcomes are request-specific or are assembled from user data. Use catalog when the outcome set is stable, reused, and managed as part of the product configuration. The decision request accepts exactly one:
or:
Do not send both fields in one request.