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.

[vinay_ba]

Thanks for u detailed answer on the dashboard validation testing.

Hi,

We also need to perform performance testing and concurrency testing of AI/BI (Lakeview) dashboards at the browser level — measuring actual page load times, time-to-interactive, and how the dashboard behaves under concurrent user load.

What we want to measure:

1. Dashboard page load time (navigation start → all widgets rendered)
2. Time to First Contentful Paint (FCP) and Largest Contentful Paint (LCP)
3. Number and duration of backend SQL queries triggered during dashboard load
4. How response times degrade when 10, 25, 50 users open the same dashboard simultaneously
5. SQL Warehouse query queuing behavior under concurrent dashboard load

Our planned approach:

1. Use Playwright (headless Chromium) to open the dashboard URL
2. Capture performance.timing, paint entries, and network request durations
3. Simulate concurrent users by launching multiple browser contexts in parallel
4. Wait for networkidle state as a proxy for "dashboard fully loaded"

Our questions:

1. Authentication What is the recommended way to authenticate programmatically for browser-based dashboard access? Can we use PAT tokens via cookie/header injection, or is there a service account login flow that avoids interactive SSO?

2. Caching behavior When multiple users open the same dashboard simultaneously, does Lakeview leverage SQL Warehouse result cache? Or does each user session trigger independent query executions?

3. Network idle as completion signal Is networkidle (no network requests for ~500ms) a reliable indicator that all dashboard widgets have finished loading? Or are there lazy-loaded widgets or progressive rendering beyond that point?

4. Published vs draft dashboard For performance testing, should we test the published dashboard URL (which may have different caching/optimization behavior) vs the draft editor view?

5. Warehouse metrics correlation Is there a way to correlate dashboard-triggered queries in Query History API (GET /api/2.0/sql/history/queries) with a specific dashboard session? For example, does Lakeview tag queries with a statement_type or source field?

6. Concurrency limits Are there known limits on concurrent sessions viewing the same AI/BI dashboard (for example: warehouse concurrency caps, connection pooling, or API rate limits)?

Environment:

• Databricks on AWS
• AI/BI Dashboard (Lakeview), published
• SQL Warehouse (serverless)
• Playwright (Python) for browser automation
• 10–50 simulated concurrent users

Thanks in advance!