Field Count Check API

This page documents how to create and manage a Field Count check via the REST API. The check uses the standard Quality Checks endpoints: set rule to fieldCount and provide the expected count as value under properties. The rule evaluates the container itself, so fields is not used. All endpoints share the base URL of your deployment (for example, https://your-instance.qualytics.io/api) and require a Bearer token.

The properties object

Field Count carries its rule-specific configuration under properties:

Create

Endpoint: POST /api/quality-checks

Permission: Member role + Author team permission on the container's datastore (Drafter when status is "Draft").

curl -X POST "https://your-instance.qualytics.io/api/quality-checks" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
      "description": "The ORDERS extract must hold exactly 9 fields.",
      "rule": "fieldCount",
      "fields": [],
      "container_id": 145,
      "properties": {"value": 9},
      "tags": ["schema", "drift"],
      "additional_metadata": {"jira": "DATA-9501"},
      "template_id": null,
      "status": "Active",
      "owner_id": 7,
      "default_anomaly_assignee_id": 12
  }'

Field notes

Three payload fields exist for other rule types but do not apply here:

• filter is rejected. Field Count is not filterable, so any non-empty expression returns 422 Unprocessable Entity. Send null or omit the field.
• coverage is rejected. The rule evaluates the container's shape, not its rows, so there is no per-row violation rate: any value other than 1 returns 422 Unprocessable Entity. Send null or omit the field.
• anomaly_message_field is ignored. Field Count emits a Shape Anomaly only, and Shape Anomalies always use the fixed message.

Read

Endpoint: GET /api/quality-checks/{id}

Permission: Member role + Reporter team permission on the check's datastore.

curl -X GET "https://your-instance.qualytics.io/api/quality-checks/101" \
  -H "Authorization: Bearer YOUR_TOKEN"

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.

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 ORDERS extract must hold exactly 10 fields.",
    "properties": {"value": 10}
  }'

A PUT can update most fields on an existing Field Count 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.

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:

curl -X DELETE "https://your-instance.qualytics.io/api/quality-checks/101?archive=true&status=Discarded&delete_anomalies=false" \
  -H "Authorization: Bearer YOUR_TOKEN"

curl -X DELETE "https://your-instance.qualytics.io/api/quality-checks/101?archive=false" \
  -H "Authorization: Bearer YOUR_TOKEN"

Error responses