Skip to main content
The Referential Checks API enables monitoring of foreign key relationships between tables. Use it to detect orphaned records, validate referential integrity, and integrate relationship checks into your data quality workflows.

Endpoints

Concepts

A referential integrity check validates that values in a child column (foreign key) exist in a parent column (primary key).
  • Child table: The table containing the foreign key (e.g., orders.customer_id)
  • Parent table: The table being referenced (e.g., customers.id)
  • Orphan: A record in the child table with no matching parent record

Get Referential Summary

Returns aggregate referential integrity statistics for an asset.

Response

List Referential Checks

Query Parameters

Response

Get Referential Check Details

Response

Create Referential Check

Requires read-write or admin scope.

Request Body

Response

Update Referential Check

Requires read-write or admin scope.

Request Body

Delete Referential Check

Requires read-write or admin scope.

Execute Referential Check

Requires read-write or admin scope.
Triggers an immediate execution of the referential integrity check.

Response

List Check Results

Query Parameters

Response

Use Case: Detect Orphaned Orders

Monitor orders that reference non-existent customers:

Use Case: Cardinality Validation

Ensure each order has a reasonable number of line items:

Error Responses

Check Not Found (404)

Invalid Table Path (400)

Check Inactive (400)

Forbidden (403)

Common Questions

Do my warehouse tables need declared foreign keys for this to work?

No. Referential checks work against any two columns you name, regardless of whether the underlying warehouse enforces or even supports FK constraints. Snowflake and BigQuery, for instance, don’t enforce FKs, which is exactly why this API exists. Just provide the child and parent table_path and column names.

When should I use max_orphan_count vs max_orphan_percent?

Use max_orphan_count=0 for hard-invariant relationships (every order must reference a real customer). Use max_orphan_percent when some drift is acceptable (e.g. late-arriving dimension rows) and you care about the rate, not the absolute count. You can set both; either threshold breach marks the check as failed.

How do min_child_count and max_child_count work?

These are cardinality constraints on the parent->children relationship. min_child_count=1 flags parents with zero children (e.g. orders with no line items), and max_child_count=100 flags parents with too many. The result returns parents_below_min and parents_above_max counts separate from the orphan count.

How expensive are referential checks on large tables?

The query joins child and parent tables, so cost scales with the warehouse’s join performance on the key columns. query_duration_ms is returned on every result for observability. For very large tables, prefer daily or weekly capture_interval and rely on execute for on-demand checks after loads rather than running them hourly.