Satisfies Expression Check API
This page documents how to create and manage a Satisfies Expression check via the REST API. The check uses the standard Quality Checks endpoints: set rule to satisfiesExpression and provide the condition under properties. The rule has no field picker: the check's field list is derived from the columns the expression names. All endpoints share the base URL of your deployment (for example, https://your-instance.qualytics.io/api) and require a Bearer token.
Tip
For complete API documentation, including request and response schemas, visit the API docs.
Permissions
All endpoints require the Member role plus a team permission on the check's datastore: Reporter to read, Author to create or update an Active check, archive, or delete, and Drafter to create or update a Draft. See Permissions for the full matrix.
The properties object
Satisfies Expression carries its rule-specific configuration under properties:
| Field | Required | Type | Description |
|---|---|---|---|
expression |
Yes | string |
The Spark SQL condition each record must satisfy. Must evaluate to true or false. Accepts Check Variables, including the built-in ones. |
Create
Endpoint: POST /api/quality-checks
Permission: Member role + Author team permission on the container's datastore (Drafter when status is "Draft").
Create a Satisfies Expression check (every accepted field)
curl -X POST "https://your-instance.qualytics.io/api/quality-checks" \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d ' {
"description": "The tax on a line must never exceed 10% of the extended price.",
"rule": "satisfiesExpression",
"fields": null,
"container_id": 145,
"coverage": 1,
"filter": null,
"properties": {
"expression": "l_tax <= l_extendedprice * 0.10"
},
"tags": ["business-logic", "pricing"],
"additional_metadata": {"jira": "DATA-10700"},
"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 "satisfiesExpression". |
fields |
No | Derived from the expression. Omit it or send null and the API extracts the column names the expression references, stores them on the check, and returns them on the response. If you do send a list, it must match the extracted columns exactly, or the request fails with 422. |
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 evaluation, so only filtered rows are evaluated. Send null for no filter. |
properties |
Yes | Object holding the expression. See above. |
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. Shape Anomalies always 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. 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. |
Read
Endpoint: GET /api/quality-checks/{id}
Permission: Member role + Reporter team permission on the check's datastore.
Retrieve a check by ID
Update
Endpoint: PUT /api/quality-checks/{id}
Permission: Member role + Author team permission on the check's datastore (Drafter when the check stays Draft).
The PUT endpoint requires description; include the check's current description (or a new one) along with the fields you want to change. Send the whole properties object: partial property updates are not merged.
Let rows with an empty tax pass
curl -X PUT "https://your-instance.qualytics.io/api/quality-checks/101" \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"description": "The tax on a line must never exceed 10% of the extended price.",
"properties": {
"expression": "l_tax IS NULL OR l_tax <= l_extendedprice * 0.10"
}
}'
A PUT can update most fields on an existing Satisfies Expression 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
descriptioncoveragefilterproperties.expressiontagsadditional_metadataanomaly_message_fieldstatusowner_iddefault_anomaly_assignee_id
Immutable
rulecontainer_idtemplate_id
Delete
Endpoint: DELETE /api/quality-checks/{id}
Permission: Member role + Author team permission on the check's datastore.
Three query parameters control what happens, mirroring the two-stage flow in the UI:
| Parameter | Default | Description |
|---|---|---|
archive |
true |
When true, the check is archived and can be restored later. When false, the check is permanently deleted. |
status |
Discarded |
The archive resolution: Discarded (no longer relevant) or Invalid (wrong and suppressed from future AI generation). Only used when archive=true. |
delete_anomalies |
true |
Whether to permanently delete the anomalies the check produced. A permanent delete (archive=false) always removes them. |
Archive a check, keeping its anomalies
Delete a check permanently
Error responses
| Status | Description |
|---|---|
400 Bad Request |
A business-logic conflict prevents the operation (for example, changing properties while the check is archived, or switching an archived check between Discarded and Invalid). |
401 Unauthorized |
Missing or invalid API token. |
403 Forbidden |
The caller lacks the required team permission on the check's datastore. |
404 Not Found |
The check ID does not exist. |
422 Unprocessable Entity |
The payload fails schema validation (for example, description missing on PUT, properties.expression missing, empty, or not a valid condition for the container, or a fields list that does not match the columns the expression references). |