We are currently attempting to build an end-to-end lineage tool using the Holistics API. Our goal is to map the full path: DW Tables → Data Models → Datasets → Dashboards/Widgets.
Why this is critical: This lineage will enable us to:
Assess the impact of DW schema changes on specific Holistics dashboards.
Identify and cleanup deprecated dashboards.
Automate metadata retrieval for dbt exposures.
We have attempted three different architectural approaches, but each is blocked by specific API bugs and mismatched documentation.
Approach 1: Top-Down (via Data Models)
Method: We used Get List Data Models to get model IDs, intending to feed them into Get object's downstream dependencies.
Blocker:Type Mismatch. The Get List Data Models endpoint returns IDs as strings, but Get object's downstream dependencies strictly requires integers. The API rejects the string input, preventing us from retrieving dependencies.
Approach 2: Bottom-Up (via Dashboards & Datasets)
Method: We used Get List Dashboard to find widgets, intending to extract query_report details to link back to the Dataset.
Blocker:Missing Response Fields. While the API documentation states the Get List Dashboard response schema includes a query_report array, the actual API response omits this field for widgets of the QueryReport type (see attached screenshot).
Method: We iterated through Get List Dashboard and then called Get a Dashboard Widget for every single widget ID to get the lineage.
Blocker:Performance/Rate Limiting. This method requires too many API calls. We consistently hit Error 61 - Connection Refused midway through the process due to the volume of widgets. This is also our least preferred method as it is inefficient compared to a targeted lineage check.
Our Ask: Could you advise on the recommended pattern for extracting this lineage? Specifically, is there a workaround for the String/Int mismatch in Approach 1, or a fix for the missing fields in Approach 2?
Our current documentation is a bit outdated, as it mixes API guidelines for multiple data asset versions, which can cause confusion.
We will update the documentation soon. In the meantime, I’d like to share some comments on your approach and our recommendations.
For clarity, we will separate data asset versions into as-code objects (newer, including Canvas Dashboard) and non-as-code objects (legacy items, including Quick Dashboard).
Regarding your approaches
Approach 1
The current Get List Data Models API only returns as-code Data Models, and their IDs which are the uname are returned as strings.
Meanwhile, Get Object’s downstream dependencies only works for non-as-code, meaning it does not accept as-code Data Models as input.
Because of this mismatch, these two APIs cannot be combined to use.
Approach 2 - 3
If you are trying to extract non-as-code Dashboards and widgets
You are correct that the Get List Dashboards API does not return query_reports as expected. I have just discussed with my engineering team and currently, we have no plan to update the API as we stopped support legacy objects like Quick Dashboards
At the moment, the only API workaround is your Approach 3, which is to additionally call Get a Dashboard Widget, which will require many more API calls
If you are extracting as-code Dashboards and widgets, there is a simpler and more consistent way:
To list dashboard details: Use List Dashboards or (List All Dashboards Metadata + Get a Dashboard), then in each dashboard response, read definition → blocks[], where each block represents a widget and contains all required information such as dataset_id and data_model_name.
To list data model details, use Get List Data Models, the ID returned is data_model_name extracted in List Dashboards API
Our recommended approach : In case you don’t want to work with APIs, and just want to extract dependency data at some specific time, we can regularly load all dependency data (Canvas, Quick Dashboards) into a Google Sheet for you to download, transform and build your own lineage.
