Skip to content

After Date Time Check API

The After Date Time check is created and managed through the standard Quality Checks API by setting rule to afterDateTime and providing a single datetime value under properties. The fields array must contain exactly one Date or Timestamp field.

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 After Date Time check.
GET /api/quality-checks/{id} Retrieve an After Date Time check by ID.
PUT /api/quality-checks/{id} Update an existing After Date Time check.
DELETE /api/quality-checks/{id} Delete (or archive) an After Date Time check.

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).
  • 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 After Date Time check on o_orderdate with a 1991-12-31 10:30 UTC cutoff. The payload below shows every field accepted by the create endpoint:

{
    "description": "Ensure that all o_orderdate values in the ORDERS table are later than 1991-12-31 10:30 UTC.",
    "rule": "afterDateTime",
    "fields": ["o_orderdate"],
    "container_id": 145,
    "coverage": 1,
    "filter": null,
    "properties": {
        "datetime": "1991-12-31T10:30:00Z"
    },
    "tags": ["migration"],
    "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 "afterDateTime".
fields Yes Array with exactly one entry. Must reference a Date or Timestamp field.
container_id Yes ID of the container (table or file) the check runs against.
coverage No Fractional value between 0 and 1. Defaults to 1 (strict; any violating row fires a Shape Anomaly).
filter No SQL WHERE expression. Applied before the comparison, so only filtered rows are evaluated. Send null for no filter.
properties Yes Object with a single key, datetime, holding an ISO-8601 timestamp string (for example, "2025-12-01T06:15:00Z"). Stored as a UTC instant.
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. After Date Time emits Record Anomalies, so this field is honored at evaluation time. 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.

What PUT Can Change

A PUT to /api/quality-checks/{id} can update most fields on an existing After Date Time 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
  • properties.datetime (move the cutoff)
  • tags
  • additional_metadata
  • anomaly_message_field
  • fields (must remain a single Date or Timestamp 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.