Any Not Null Check API

The Any Not Null check is created and managed through the standard Quality Checks API by setting rule to anyNotNull and listing the fields to evaluate under fields. The rule has no additional properties, so properties is an empty object.

Tip

For complete API documentation, including request and response schemas, visit the API docs.

Endpoints

Method	Path	Purpose
`POST`	`/api/quality-checks`	Create a new Any Not Null check.
`GET`	`/api/quality-checks/{id}`	Retrieve an Any Not Null check by ID.
`PUT`	`/api/quality-checks/{id}`	Update an existing Any Not Null check.
`DELETE`	`/api/quality-checks/{id}`	Archive an Any Not Null check (the default), or delete it outright.

Permissions (on the target container's team):

POST and PUT for an Active check: Author team permission (or above).
POST and PUT for a Draft check: Drafter team permission (or above), as long as the request keeps the check in Draft. Activating a Draft check (setting status to Active) requires Author team permission (or above).
DELETE: Author team permission (or above).
GET: Reporter team permission (or above).

The team-permission hierarchy is Editor > Author > Drafter > Viewer > Reporter. "Or above" includes every higher level.

Payload Example

Create an Any Not Null check on the orders table so every row must carry either o_comment or o_orderstatus. The payload below shows every field accepted by the create endpoint:

{
    "description": "Ensure that every order in the ORDERS table carries either a comment or a status.",
    "rule": "anyNotNull",
    "fields": ["o_comment", "o_orderstatus"],
    "container_id": 318,
    "coverage": 1,
    "filter": null,
    "properties": {},
    "tags": ["orders", "completeness"],
    "additional_metadata": {"jira": "DATA-1234"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Field Notes

Field	Required	Notes
`description`	Yes	Free-text description shown in the UI.
`rule`	Yes	Must be `"anyNotNull"`.
`fields`	Active only	Array of field names; at least one is required for an Active check, and the rule is designed for two or more. Each field must exist on the container and be active. A row passes if at least one of the listed fields is non-NULL on that row. Any field type is accepted. With a single field the behavior is identical to Not Null, so use Not Null instead. A Draft check can be saved before the field list is complete.
`container_id`	Yes	ID of the container (table or file) the check runs against.
`coverage`	No	Fractional value between `0` and `1` that defines the minimum fraction of evaluated rows that must pass. Defaults to `1`, which requires every row to pass.
`filter`	No	SQL `WHERE` expression. Applied before the check, so only filtered rows are evaluated. Send `null` for no filter.
`properties`	No	Any Not Null has no rule-specific properties. Send `{}` or omit.
`tags`	No	List of tag names applied to the check for filtering and organization.
`additional_metadata`	No	Free-form key-value pairs (typically links to catalog entries, tickets, governance records).
`anomaly_message_field`	No	Name of a source-record field whose value should be used as the Record Anomaly message instead of the default template-generated one. When the named column is null, missing, or empty for a violating row, the standard Record template is used instead. Applies only to Record Anomalies; Shape Anomalies use the fixed template. Send `null` to use the default Record template.
`template_id`	No	ID of a Check Template to associate the check with. `null` if not using a template.
`status`	No	`"Active"` (default) or `"Draft"`. Draft checks are not evaluated by Scans.
`owner_id`	No	ID of the user who owns the check. The user must have at least the Drafter team permission on the datastore. Defaults to the user creating the check when omitted.
`default_anomaly_assignee_id`	No	ID of the user automatically assigned to anomalies produced by the check. The user must have at least the Viewer team permission on the datastore.

What `PUT` Can Change

A PUT to /api/quality-checks/{id} can update most fields on an existing Any Not Null check. Three values stay immutable: the rule type, the container the check is attached to, and the associated Check Template. If any of these needs to change, delete the check and create a new one.

Editable vs Immutable on PUT

Editable

description
coverage
filter
fields (add or remove field names; at least one required when Active)
tags
additional_metadata
anomaly_message_field
status
owner_id
default_anomaly_assignee_id

Immutable

rule
container_id
template_id

Introduction: formal definition, field scope, and general/anomaly properties.
How It Works: full semantics, NULL handling, filter behavior, and anomaly templates.
Examples: three production scenarios with sample data and resulting anomalies.
FAQ: short answers to the most frequent questions.