Skip to main content
POST
Validate a CEL condition
Checks whether a CEL expression is valid without creating a rule. Pass the condition string in the request body. The response returns a valid boolean and a message with details. Pass an optional program_id to validate references against a specific program: tier keys and asset symbols in the expression are checked against that program’s configuration, and the response includes non-blocking vocabulary warnings. Pass an optional draft actions array to run the same checks on action expressions (template syntax, CEL compilation, references) before creating the rule. Field references to event.* are never validated because events are schemaless. For example, event.amount > 100 passes even if your events never include an amount field. Use the simulate endpoint to test a rule against realistic data.
For usage patterns and examples, see the Writing Rules guide.

Authorizations

X-API-Key
string
header
required

API key passed in the X-API-Key header.

Body

application/json

Condition to validate

condition
string
required

CEL expression to validate

Minimum string length: 1
Example:

"event.type == 'purchase' && event.amount > 100"

actions
Rule action (draft) · object[]

Draft actions to check along with the condition. Incomplete actions are accepted. Expressions are checked as they are when saving a rule. With program_id, validation also checks asset restrictions and recognizes keys these actions set, so reading those keys does not produce an unknown-key warning.

program_id
string<uuid>

Program to check the draft against. Checks tier keys and warns about counters, tags, or attributes that no rule in the program sets. With actions, also checks whether the asset supports expires_at, matures_at, and reference_id, plus reference_id length and format. Without program_id, checks cover tier field structure, participant fields, and deprecated names.

Example:

"550e8400-e29b-41d4-a716-446655440001"

rule_id
string<uuid>

Rule you are editing. Excludes its saved actions from the known state keys so renaming a key in the draft does not hide a warning. Omit when creating a rule.

Example:

"550e8400-e29b-41d4-a716-446655440002"

Response

Validation result

message
string

Human-readable validation result or error detail

Example:

"CEL condition is valid"

note
string

Additional context about validation scope (present only on success)

Example:

"Validation checks syntax only. Field references are not verified against an event schema."

valid
boolean

Whether the condition is syntactically valid

Example:

true

warnings
object[]

Non-blocking advisories — e.g. a counter/tag/attribute key referenced in a condition/action expression that no rule in the program writes (likely a typo), or a deprecated CEL alias. Never affects validity.