How to programatically extract rendered or computed data from AIBI Lakeview dashboard widget via API

[vinay_ba]

Hi,

We're building an automated data quality testing framework for AI/BI (Lakeview) dashboards. Our goal is to validate that dashboard widgets display correct data without using UI automation (Selenium/Playwright don't work reliably due to React dynamic DOM and Canvas rendering).

What we've tried so far:

1. GET /api/2.0/lakeview/dashboards/{dashboard_id} Returns the dashboard definition (serialized_dashboard JSON with datasets, queries, widgets, measures). This is metadata only — no computed data.
2. GET /api/2.0/workspace/export?path=/path/to/dashboard.lvdash.json Returns the same .lvdash.json definition file. Again, no data.
3. GET /api/2.0/lakeview/dashboards/{dashboard_id}/published Returns published dashboard metadata (warehouse ID, publish time). No computed data.
4. SQL Statement Execution API (POST /api/2.0/sql/statements) We extract queries from the dashboard definition and execute them ourselves. This works, but we're reconstructing what the dashboard does rather than reading what the dashboard actually renders.
5. Jobs API (views_to_export=DASHBOARDS) Requires a job run with a dashboard task. Not applicable to standalone AI/BI dashboards.

Our current approach:

• Extract base queries from datasets[].queryLines[] in the dashboard definition
• Resolve MEASURE() references from columns[] definitions
• Apply filters as WHERE clauses (same way Lakeview does internally)
• Execute via databricks-sql-connector on the same SQL Warehouse
• Compare results against independently written expected queries

Our question:

Is there any API endpoint (current or planned) that returns the actual computed/rendered data from a Lakeview dashboard widget — i.e., the exact result set that the dashboard displays to the user after applying filters?

For example, something like:

GET /api/2.0/lakeview/dashboards/{id}/widgets/{widget_id}/data?filters=...

Or is extracting the query from the definition and executing it ourselves the recommended approach for programmatic data validation of AI/BI dashboards

Thanks in advance!

[Ashwin_DSA]

Hi ,

My view is that the testing approach should focus on validating the underlying data and query logic, rather than the rendered visual itself.

AI/BI Dashboards are built from datasets, visualisations, and filters. In other words, the chart or table a user sees is a presentation of a dataset after aggregations, filtering, and formatting have been applied. If the goal is data quality validation, the most stable thing to test is the data contract behind the dashboard which includes source tables, views, metric definitions, dataset SQL, and expected filter behaviour.

That is usually a better fit than testing "what the widget rendered" for a few reasons:

• Visuals are not the source of truth. The source of truth is the underlying dataset and business logic.
• Dashboards can apply visualisation-specific filtering and aggregation differently depending on dataset size and execution path.
• Rendering itself has limits and optimisations, so validating the visual can end up mixing data correctness with presentation/runtime behaviour.

Databricks documents this behaviour explicitly. For smaller datasets, the dataset result can be pulled to the client, and visualisation-specific filtering and aggregation are performed in the browser. For larger datasets, visualisation-specific filtering and aggregation are performed on the backend instead. That means there is not always a single simple "widget result" object exposed as a stable public API contract that exactly represents what was rendered.

So in practice, I would recommend:

1. Validate the source tables/views or metric views.
2. Validate the dashboard dataset SQL.
3. Validate expected filter semantics and aggregations.
4. Use dashboard-level checks only as smoke tests to confirm the dashboard is wired correctly.

That last point matters. There is still value in lightweight dashboard tests, for example:

• confirming the right filters affect the right widgets
• confirming expected aggregations are shown
• confirming cross-filtering or drill-through behaves as expected

But I would treat those as product behaviour checks, not as the primary layer for data quality testing.

So the short version is.. validating the underlying data is the better and more reliable approach than validating the visuals themselves. The visuals are important for user experience, but the data layer is the right place to anchor automated correctness tests.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.