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, and the functions it may call beyond CEL’s own operators and standard functions. 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 signal.ext. names your rules read off an evaluation and the param. names a recipe 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.

GET /v2/watch/management/rules/catalog

List signals

cURL

curl --request GET \
  --url https://api.prelude.dev/v2/watch/management/rules/catalog \
  --header 'Authorization: Bearer <token>'

200

{
  "signals": [
    {
      "name": "signal.ip",
      "type": "bool",
      "description": "The end user's IP address: the one sent with the evaluation request, or the one the Prelude SDK collected."
    }
  ],
  "functions": [
    {
      "name": "net.inCIDR",
      "description": "Returns true if the IP address is in one of the CIDR ranges, false otherwise. An empty or invalid IP address returns false. An invalid CIDR range is an error.",
      "signatures": [
        "net.inCIDR(<string>, <list<string>>) -> <bool>"
      ],
      "examples": [
        "net.inCIDR(signal.ip, [\"203.0.113.0/24\", \"2001:db8::/32\"])"
      ]
    }
  ]
}

A signal is a name Prelude resolves for the evaluation being scored: a fact about the request, the device, or the number that Prelude determines for you. Every customer gets the same signals, and each one means the same thing for all of them.

Each entry is listed under the signal. identifier a rule writes it as, so name is what you put in an expression.

Functions

The listing also documents the functions a rule can call beyond CEL’s own operators and standard functions: the network, string, list, set and regex extensions. Each function has its signatures, a description of what it returns, and examples you can copy into a rule. Each example is a valid rule expression.

Your own values are separate

A rule can also read your own signals, as signal.ext.<key>, and the param. names its recipe is configured with. Those belong to you and they are not listed here. They are kept apart from the listed signals, so nothing Prelude adds to this listing can collide with a name of yours.

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 reports NOT_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. name it does not list does not resolve in a rule of yours, and an expression referencing one is refused with Unsupported signal `signal.<name>` .

Authorizations

Authorization · string · header · required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Response

200

application/json

OK

signals · object[] · required

Show child attributes

functions · object[] · required

The functions a rule expression may call beyond CEL's own.

Show child attributes