get_source_config

Reads back the stored refresh manifest that drives scheduled refresh, exactly as stored: manifest_version, connection, schedule, the SQL, dimensions, measures, any format and derived fields, and for a row-level manifest the schema and data block.

Read-only. To change the manifest, republish the dashboard with an updated source_config through publish_dashboard, or edit the spec and republish that.

Behaviour hints for clients: read-only, not open-world.

Parameters

Parameter	Type	Required	Notes
slug	string	yes	Canonical slug of the dashboard whose manifest to read.
workspace	string	no	Workspace slug.

Returns

The pretty-printed manifest, then a JSON block:

Refresh manifest for "revenue-overview" (frequency: daily):
Connection: Analytics Postgres [7a1e...]
{
  "manifest_version": 3,
  "connection": "7a1e...",
  "schedule": "daily",
  "cube_sql": "select ..."
}

BEGIN_JSON
{"slug":"revenue-overview","dashboard_id":"...","is_refreshable":true,"connection":"7a1e...","connection_label":"Analytics Postgres","frequency":"daily","source_config":{}}
END_JSON

A dashboard with no manifest is a success, not an error:

"<slug>" has no refresh manifest - it is not a refreshable dashboard. Republish it with a source_config manifest via your AI tool to put it on a schedule.

Errors

The shared slug rules, plus:

Condition	Text
The read failed	source_config lookup failed: <err>
No such dashboard	No dashboard named "<slug>" in your account.

That second refusal says in your account even when the target is a workspace. See Scope.

Scope

Workspace-capable. Any member of the workspace may read the manifest of its dashboards.

Check it worked

Compare the connection in the manifest against the connection you intended. This is the fastest way to catch the scope trap: a workspace dashboard whose manifest names a personal connection publishes fine and can never refresh, and the manifest is where that mismatch is visible.