Skip to main content
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 a first-class part of the catalog — it appears in lineage, carries a schema, has a status, is covered by checks, and can be owned, alerted on and put in a data product like anything else.

What you can express

When you need one

Reach for a custom integration when the thing you care about is not addressable in a warehouse. If it has a table name, Coalesce Quality can already see it through the warehouse integration, and the more direct routes are the ones to use: 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:
Three of those four hops use a different mechanism, because each hop has different information available. Choosing correctly per hop is the part worth thinking about; Modelling your tool is the decision.

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

Questions about modelling a tool of your own go to your Technical Account Manager — see Support.