Custom Integrations

Coalesce Quality ships integrations for warehouses, dbt, SQLMesh, orchestrators, BI tools and catalogs. This section is about everything else: a tool you built in-house, one you are piloting, a streaming platform, a reverse-ETL job, a machine learning pipeline, an internal service that reads a table and writes a file. You describe it over the public API, and it becomes part of the catalog like any other entity. It appears in lineage, carries a schema, has a status and is covered by checks. You can give it owners, alert on it and put it in a data product.

What you can express

Concept	What it is
Entity type	A kind of thing in your tool: `Kafka Topic`, `Feature View`, `Notebook`. Carries an icon and behavioural traits
Entity	One instance of that kind: a slug id for machines, plus a name, description and annotations for people
Schema	The columns the entity has, so column-level lineage and column-level checks can reach it
Lineage	What flows into it: derived from SQL, declared column by column, or stated as a plain edge
Executions	The runs of the entity, so it has a health status
Checks	Entities that validate other entities, attached to what they check
Code	The SQL, Python or configuration behind the entity, and the file in Git it lives in
Group	The set of entities your integration owns, which is what makes deletion work

When you need one

Use a custom integration when the thing you care about is not addressable in a warehouse. If it has a table name, Coalesce Quality already sees it through the warehouse integration. For these, use the existing integrations:

A dbt or SQLMesh project: use the dbt or SQLMesh integration.
Airflow, or any orchestrator that speaks OpenLineage: use the orchestration integrations.
A BI tool we support: Looker, Tableau, Omni.
Tests you already run in the warehouse: SQL tests express those without any code.

Everything else is a custom integration: a BI tool we have no connector for, a Kafka topic, an S3 export, a feature store, an internal API that serves a dataset, a Python job that transforms data outside SQL.

What it looks like when it works

A field on a dashboard that runs no SQL at all, in a tool with no integration, traced back to the physical warehouse columns it came from:

dashboard.revenue_by_category.revenue
  <- question.revenue
       <- model.net_revenue
            <- order_items.quantity
            <- order_items.unit_price
            <- order_items.discount

The hops use different mechanisms, because each hop has different information available. Modelling your tool explains how to choose one per hop.

Where to go next

Modelling your tool

Which lineage mechanism for which hop, what traits do, and the two mistakes that produce a valid-looking write and an empty graph

Building an integration

The walkthrough: credentials, types, entities, features, groups, executions, verification

API surface

Every service and method involved, the scope each one needs, and the limits

Worked examples

Runnable Go and Python programs, including a whole BI tool modelled end to end

Support

For questions about modelling your own tool, contact your Technical Account Manager. See Support.

Get Started

Alerts

Monitors

Monitors Types

Reconciliations

Data Products

Scout AI

Ownership

Incidents

Analytics

Query activity

Lineage

BI Integrations

Data Warehouse Integrations

Transactional databases

Code Integrations

dbt Integrations

SQLMesh Integrations

Coalesce Integrations

Orchestration Tool Integrations

Alerting Integrations

Catalogs

Google Cloud Integrations

Admin

Security

Support

Developer API

What you can express

When you need one

What it looks like when it works

Where to go next

Modelling your tool

Building an integration

API surface

Worked examples

Support