Bulk management of Allowed Domains for embedded dashboards

What is the problem or goal you're trying to solve or accomplish?

Allowed Domains for dashboard embedding is configured per-dashboard via the Embed dialog. When a customer needs to add (or remove, or rotate) a domain across many dashboards — for example, after introducing a new application domain, migrating environments, or deprecating an old one — there is no native way to apply the change in bulk. Customers with dozens or hundreds of embedded dashboards, especially those operating across multiple workspaces, must update each dashboard one by one, which is time-consuming and error-prone. The risk grows when changes are urgent (e.g., a domain change tied to a product launch or security event), where missing a dashboard can cause embedding to break for end users.

This was raised by a customer who recently added a new application domain and wanted to enable embedding from it across all dashboards in all their workspaces without manually editing each one.

How are you solving it currently?

We direct customers to the Preset/Superset REST API, specifically the /api/v1/dashboard/{id}/embedded endpoint. Customers write a script that iterates over each workspace, lists dashboards with embedding enabled, fetches the current allowed_domains list for each, merges the new domain, and POSTs the updated list back. This works but has several drawbacks:

• Requires programming skills and Preset API credentials, which not all customers have on hand.

• The POST endpoint replaces the entire allowed_domains list rather than appending, so a naïve script can silently wipe existing domains. This is a real footgun.

• It only operates on dashboards that already have embedding enabled — there's no bulk path to enable embedding with a starting domain set on dashboards that don't yet have it.

• Scoping is manual: there is no built-in filter for "all dashboards in workspace X" or "all dashboards tagged Y," so the customer has to handle filtering themselves.

• Mistakes are hard to undo since the endpoint doesn't track history of previous allowed domains.

What is your recommended solution?

Introduce a UI and/or API capability for bulk management of Allowed Domains across embedded dashboards. Ideally:

• A Manager-level (or workspace-level) UI panel that lists all dashboards with embedding enabled and allows administrators to add, remove, or replace domains across a selection. Selection should support "all dashboards in workspace," "all dashboards across workspaces in a team," and selection by tag or owner.

• A diff-style preview before applying changes so administrators can confirm what will be modified.

• An "append domain" operation (in addition to the existing "replace") in the API so customers can safely add a domain without first reading and merging the current list. This alone would dramatically reduce the risk of the current scripting workaround.

• Optionally, a global Allowed Domains list at the workspace or team level that applies to all embedded dashboards in scope, with per-dashboard overrides. This would centralize domain governance and make adding/removing a domain a single action rather than N actions.