List the signals a rule can read
Beta. The request and response shapes may still change.
List the Prelude signals a rule expression may reference. A signal is a name Prelude resolves for the evaluation being scored, and it means the same thing for every customer. Write it in an expression and compare it like any other value of its type.
Prelude provides these names. The rest of a rule’s vocabulary is yours - the attr. names a recipe declares and the param. names it is configured with - and those do not appear here.
A signal may be absent from an evaluation, whatever its type. A rule that reads a signal that did not arrive reports NOT_EVALUATED rather than treating the missing value as a zero.
Prelude publishes the catalog progressively, so this listing grows over time. Write rules against what it returns: a signal it does not list is one Prelude has not committed to, and it can change or be removed without notice.
Your own values are separate
A rule can also read theattr. names a recipe declares and the param. names it is configured with. Those belong to you, they exist only in the recipe that declares them, and they are not listed here.
An absent signal is not a zero
Any signal can be missing from a given evaluation. A rule that reads a signal that did not arrive reportsNOT_EVALUATED instead of scoring. It does not read the absence as false, as 0, or as an empty string. Write the condition you mean, and let the engine report the absence.
The listing grows
Prelude publishes the catalog progressively, so this listing grows over time. Treat it as the supported vocabulary: a signal it does not list is one Prelude has not committed to, so read it rather than keeping a copy.Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Query Parameters
Maximum number of signals to return per page. A larger value is clamped to 200 rather than refused.
1 <= x <= 200Pagination cursor from the previous response.