tile_changes and layout. Use the id directly:
list_dashboards may not show it
yet.
reports adds each report as the tiles it can render (see its
available_visualizations in
list_reports); a report’s
visualization_types narrows that to its chart or its pivot table.
layout_rows places them, new tiles being named by their report_id. Omit
both to create it empty and fill it later with
update_dashboard.
Read the outcome on every tile_changes row before reporting success. The
dashboard is created either way: a report that could not be added leaves the
page emptier than asked, not the call failed. Removing a tile is still a job for
the Qobra web app. layout is the page as it was created, read back from the
dashboard: where each new tile landed.
Every write to the live environment is recorded in the audit trail as the Qobra MCP agent; writes to a sandbox are not audited.
Parameters
Body
Body
string
required
Name of the dashboard.
string
Free-text note about what the dashboard is for.
object[]
Reports to add, each as every tile it can render unless its
visualization_types narrows it. Omit to create it empty.
string[][]
The whole arrangement, rows top to bottom, each row’s tiles left to right.
An entry is a visualization_id from get_dashboard, or a report_id (every
tile of that report: the only way to place tiles this same call adds). A row
holds at most three charts, or two tiles when one is a pivot table; an
overflowing row is split. A tile you leave out goes after the others, one
per row. Omit to leave the arrangement alone; [] resets it, one tile per
row.
string
Id of a sandbox from list_sandboxes, to create this in instead of the live
environment. Omit it to create in live, the company’s real data. Never a
name, never the live id.
Example
Create a dashboard with the charts of two reports, side by side on one row, and the pivot table of a third report on a row below:report_id entry in layout_rows places every tile that report adds. A row
holds at most three charts, or two tiles when one is a pivot table, and Qobra
splits a row that overflows. Read layout in the response to see where each
tile landed.
Response
Body
Body
object
The dashboard as it now exists — the same row list_dashboards returns, so
the id can be reused straight away.
object[]
What became of each report you passed, one row per tile: a report added as
both a chart and a pivot table gets a row for each, so does each type you
asked for that the report lacks, and one not found or with no tile at all
gets a single row, with visualization_type null. Read
outcome on each
before reporting success, since a call can succeed having added nothing you
asked for. Empty when no reports were passed.object[]
The dashboard’s rows as they now stand, top to bottom, each tile left to
right — read back from the dashboard, so it shows where every tile actually
sits. A tile this call added lands on a row of its own at the end. Empty
when the dashboard has no tile yet. Rows passed in layout_rows are applied
after the reports are added and come back as the store took them: a row
holds at most three charts or two pivot tables and is split when it
overflows, and a tile you left out keeps its place on a row of its own.
object[]
One row per layout entry you passed, saying what became of it. Empty when no
layout_rows were passed.