Update a custom view (experimental)
Update a custom view (experimental)
Authentication
Path parameters
Request
New human-readable view name.
New description; pass null to clear it.
Full replacement of the view’s query list. Each SQL is re-validated (SELECT-only) exactly like createCustomView. For changing one or two queries, prefer queryUpserts/queryRemovals instead. Cannot be combined with them.
Replacement render bundle. Re-validated (size cap, self-contained, paid:data listener) exactly like createCustomView. For small changes, prefer bundleEdits instead. Cannot be combined with bundleEdits.
PREFERRED for revisions: exact search-and-replace edits applied in order to the stored render bundle, so you send only the changed text instead of re-transmitting the whole bundle. The edited result passes the same validation as a full replacement. Cannot be combined with renderBundle.
PREFERRED for revisions: per-query changes — each entry replaces the stored query with the same id, or is appended as a new query. Queries not mentioned are left unchanged. Cannot be combined with queries.
Ids of stored queries to remove (applied before queryUpserts). Rejected if an id does not exist. Cannot be combined with queries.
Response
Stable public identifier used in preview/embed URLs.
A view is DRAFT until explicitly published; only PUBLISHED views are served to end-customers.
‘customer’: data is scoped to one viewing customer and the view is embeddable per-customer. ‘organization’: data is org-wide and the view is internal-only.