Solution: Yes—there is a better-supported path than relying on

system/config-update

for this use case. Based on the REST docs,

updateSystemConfig

only accepts a generic

configuration

object, and the docs do not publish a key whitelist for redirect-link behavior. So your confusion is expected. I could not find this in the official ThoughtSpot documentation. For multi-Org URL/security behavior, use: -

POST /api/rest/2.0/system/security-settings/configure

-

cluster_preferences

for cluster-level values -

org_preferences

for Org-specific values (including

org_identifier

) - Currently documented Org-level keys are: -

cors_whitelisted_urls

-

non_embed_access

If your requirement is “each Org has its own customer-facing host” (for example

test1.analytics.com

,

test2.analytics.com

), this endpoint is the documented one for Org-scoped security preferences. For SAML redirect URLs, docs currently show this only under

cluster_preferences.saml_redirect_urls

(not Org-level). --- Suggestions: - Treat

system/config-update

as low-discoverability for typed keys; use

system/security-settings/configure

where schema is explicit. - If you need truly Org-specific redirect URL behavior for SAML/login callbacks (not just embed host/CORS behavior), that appears to be a product/tenant-architecture question—raise with ThoughtSpot Support/CSM since Org-level

saml_redirect_urls

is not documented. - Validate current state first with: -

GET /api/rest/2.0/system/config

(cluster config snapshot) - then apply

system/security-settings/configure

incrementally per Org. --- Docs: - REST API v2 overview: https://developers.thoughtspot.com/docs/rest-api-v2 - Security settings (cluster + Org preferences): https://developers.thoughtspot.com/docs/security-settings - API Playground (your cluster): https://thoughtspot.humanforce.com/#/develop/api/rest/playgroundV2_0