Quality Check Ownership API¶

This page documents how to read and change the Owner of a quality check via the REST API. Ownership is exposed on the standard Quality Checks endpoints (there is no dedicated ownership route) through a single owner_id field on create/update payloads and query parameters on the list endpoints (owner_id on GET /quality-checks, owner=true on GET /quality-checks/listing). 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. Reads need the Viewer team permission on the check's datastore; writes (create, update, bulk update) need the Author team permission. The user targeted by owner_id must independently have at least the Drafter team permission on the same datastore.

The `owner_id` field¶

Every quality check carries a single owner. The API exposes it as owner_id on writes and as a nested owner object on reads.

Field	Type	Description
`owner_id`	`int`	The user ID of the check owner. On `POST`, defaults to the caller (or to the `Qualytics` user on AI Managed (inferred) checks). On `PUT`/`PATCH`, omit (or send `null`) to leave the owner unchanged. The target user must have at least the Drafter team permission on the check's datastore.

Example owner field on a read response (abbreviated)

{
  "id": 101,
  "rule_type": "unique",
  "inferred": false,
  "owner": {
    "id": 42,
    "name": "Alice Lee",
    "email": "alice@example.com"
  }
}

Create¶

Create a check with an explicit owner¶

Endpoint: POST /api/quality-checks

Permission: Member role + Author team permission on the container's datastore. The target owner_id must have Drafter on the same datastore.

Include owner_id in the create payload to set an explicit owner. Omit the field to let the platform default to the caller.

Example request

curl -X POST "https://your-instance.qualytics.io/api/quality-checks" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "description": "Ensure C_NAME is unique in the CUSTOMER table",
    "rule": "unique",
    "fields": ["C_NAME"],
    "container_id": 145,
    "owner_id": 42
  }'

Update¶

Transfer ownership on a single check¶

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

Permission: Member role + Author team permission on the check's datastore. The target owner_id must have Drafter on the same datastore.

Send owner_id set to the new owner's user ID. The previous owner is recorded in the check's history.

A PUT replaces the check's assertion, so send the current description and properties from GET /api/quality-checks/{id}, an array of each returned field's name as fields, and the new owner_id. For an owner-only change, the bulk update is simpler because it needs only id and owner_id.

Example request

curl -X PUT "https://your-instance.qualytics.io/api/quality-checks/101" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "description": "Ensure C_NAME is unique in the CUSTOMER table",
    "fields": ["C_NAME"],
    "properties": null,
    "owner_id": 42
  }'

This Unique check has no properties, so properties is null, as the GET returns it. For a check that has properties, send the properties object exactly as the GET returns it. Leaving properties out clears them.

AI Managed conversion still applies

For AI Managed (inferred) checks owned by Qualytics, changing the value of any assertion property (properties, coverage, filter, or fields) in the same payload also transfers ownership to the editor and flips inferred from true to false. To transfer ownership of an AI Managed check and keep inferred as true, use the bulk update with only id and owner_id.

Transfer ownership across many checks¶

Endpoint: PATCH /api/quality-checks

Permission: Member role + Author team permission on the datastore of every check in the request. The target owner_id must have Drafter on each of those datastores.

Send a list of { id, owner_id } entries; the same owner_id can be reused across entries to apply one owner to many checks. The same endpoint also takes the other bulk fields, such as tags and additional_metadata, with tags_mode and additional_metadata_mode set to replace (the default) or add; owner_id always replaces the current owner.

Bulk is all-or-nothing

If any entry references a check the caller cannot update (404 not found, missing Author on the datastore, or the target owner_id lacks Drafter), the entire request is rejected and no checks are updated. Retry with the offending entry removed.

Apply the same owner to many checks

curl -X PATCH "https://your-instance.qualytics.io/api/quality-checks" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '[
    { "id": 101, "owner_id": 42 },
    { "id": 102, "owner_id": 42 },
    { "id": 103, "owner_id": 42 }
  ]'

Filter¶

Filter checks by a specific owner¶

Endpoint: GET /api/quality-checks

Permission: Member role. Results are scoped to datastores the caller can see.

Use the owner_id query parameter to narrow the list to checks owned by a specific user. Combine with the other list filters (status, tags, rule type, and so on) to scope further.

List checks owned by user 42

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

List checks owned by the current user¶

Endpoint: GET /api/quality-checks/listing

Permission: Member role.

The aggregated listing endpoint accepts owner=true, which scopes the result to checks owned by the user issuing the request. This is the same filter the UI uses for the Owned subtab.

Equivalent of the Owned subtab

curl -X GET "https://your-instance.qualytics.io/api/quality-checks/listing?owner=true&count_perspective=checks" \
  -H "Authorization: Bearer YOUR_TOKEN"

Error responses¶

Status	Description
`400 Bad Request`	A business-logic conflict prevents the operation (for example, attempting to change properties while the check status is invalid or discarded).
`401 Unauthorized`	Missing or invalid API token.
`403 Forbidden`	The caller lacks Author on the check's datastore, or the target `owner_id` lacks Drafter on the same datastore.
`404 Not Found`	The check ID or `owner_id` user does not exist.
`422 Unprocessable Entity`	The payload fails schema validation (for example, a required field such as `description` is missing on `PUT`, `owner_id` is not an integer, or `properties` contains an unrecognized key for the rule type).

Introduction: overview of ownership and the four transfer modes at a glance.
How It Works: full mechanics: defaults, the four transfer modes in detail, permissions, notifications, history, and filtering.
Change Check Owner: UI walkthrough that mirrors PUT /api/quality-checks/{id}.
Bulk Change Check Owner: UI walkthrough that mirrors PATCH /api/quality-checks.
FAQ: short answers to the most common ownership questions.