Docs / Contact / services/validation-rules

Validation Rules

Services use validation rules to check message data. Each rule applies an operator to a specific field in the message payload.

Rule Format#

Each rule consists of:

field -- The path to the field in the message data (e.g., temperature, location.lat)
operator -- The comparison to perform
value -- The expected value or range
message -- (Optional) Custom error message when the rule fails

Available Operators#

Equality#

Operator	Description	Example
`eq`	Equal to	`temperature` eq `22.5`
`ne`	Not equal to	`status` ne `"error"`

Comparison#

Operator	Description	Example
`gt`	Greater than	`temperature` gt `0`
`lt`	Less than	`temperature` lt `100`
`ge`	Greater than or equal	`count` ge `1`
`le`	Less than or equal	`humidity` le `100`
`between`	Within a range (inclusive)	`temperature` between `[-50, 150]`

String#

Operator	Description	Example
`startsWith`	Starts with substring	`device_id` startsWith `"SN-"`
`endsWith`	Ends with substring	`filename` endsWith `".json"`
`contains`	Contains substring	`name` contains `"sensor"`

Set Membership#

Operator	Description	Example
`in`	Value is in the set	`unit` in `["C", "F", "K"]`
`notIn`	Value is not in the set	`status` notIn `["disabled", "deleted"]`
`hasAll`	Array contains all values	`tags` hasAll `["active", "monitored"]`
`hasAny`	Array contains at least one	`capabilities` hasAny `["mqtt", "http"]`

Type#

Operator	Description	Example
`isTimestamp`	Value is a valid timestamp	`created_at` isTimestamp `true`

The timeRange operator is also available for checking that a timestamp field falls inside a window.

Rule Evaluation#

All rules in every dynamic action are evaluated for each publish message the entity sends.
A rule whose field is absent from data is skipped, not failed. List the field in requiredFields if its absence should fail.
Rules are evaluated independently -- a failure in one rule does not prevent other rules from being checked.
A message's overall validation_status is passed only if every rule (and every required field) passes; otherwise it is failed.

Validation is passive, not blocking

Failing validation does not reject the message. The message is still stored regardless of outcome; it is simply marked validation_status: "failed", with the per-rule results attached as actionResults. To handle failures, route on the tags the failing dynamic action injects (see Creating Services) rather than expecting an error response.

Next Steps#

Creating Services -- Build services with these rules

← Back to Contact docs