Bug Report: API Type Mismatches and Missing Fields blocking visibility on end-to-end lineage

Hi Team,

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).

Approach 3: Iterative Extraction (via Dashboard Widgets)

  • 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?