Programmatically deploy content from a parent organization to tenants
You can use the Sigma REST API to deploy content from a parent organization to one or more tenant organizations.
This document outlines the required endpoints and follows one example end-to-end. For the equivalent steps in the Sigma UI, and for details about what content gets deployed and other considerations, see Deploy content from a parent organization to one or more tenants.
An admin in the parent organization can programmatically perform the following steps. For steps that need to be performed in a tenant organization, the admin can impersonate each tenant for API calls.
Example scenario
The following steps deploy a Quarterly sales dashboard workbook from a parent organization to two tenant organizations, Acme West and Acme East. Each tenant has its own Snowflake connection that the workbook’s parent connection must be swapped to on deployment.
Steps
Retrieve connection information
For the parent organization and each target tenant, retrieve the connection ID and name information. Use List connections (GET /v2/connections).
In this example, the parent organization’s connection list includes Snowflake Example:
Impersonate each tenant and call the endpoint again to retrieve that tenant’s connection. In this example, the Acme West tenant’s connection list includes Snowflake - Tenant Example:
Create a user attribute
In the parent organization, create a user attribute (POST /v2/user-attributes) to hold the tenant connection to swap to.
The response returns a userAttributeId:
Assign the user attribute to tenants
Assign the user attribute to target tenants with the value of the relevant connection ID for each tenant. Use Set a user attribute for tenants (POST /v2/user-attributes/{userAttributeId}/tenants).
Create a source swap policy
Create a source swap policy with a type of deployment. Provide the user attribute as the toConnection parameter.
The response returns a policyId:
Create a deployment policy
In the parent organization, create a deployment policy (POST /v2/deploymentPolicies). For the sourceSwapPolicies parameter in the request body, provide one or more source swap policies.
The response returns a deploymentPolicyId:
Add documents and folders to the deployment policy
Add documents and folders to the deployment policy (POST /v2/deploymentPolicies/{deploymentPolicyId}/files).
To identify which documents to add, call the relevant endpoint and use the relevant IDs in the inodeIds option:
- List workbooks and use the
workbookIdin the response. - List reports and use the
reportIdin the response. - List data models and use the
dataModelIdin the response. - Retrieve folder IDs with the List files (
GET /v2/files) endpoint and use the relevantinodeIdin the response.
You can provide up to 100 IDs per request. In this example, the Quarterly sales dashboard workbook has a workbookId of 6a1d8f3b-2e5c-4b7a-9d1e-4c8b6a3f7e2d:
Add tenants to the deployment policy
Add each tenant to the deployment policy (POST /v2/deploymentPolicies/{deploymentPolicyId}/tenants). Call the endpoint once per tenant:
After both calls succeed, Quarterly sales dashboard is deployed to both Acme West and Acme East, with each tenant’s connection swapped in for the parent connection.
You cannot retrieve the status of a deployment through the REST API. To review the status, use the Sigma UI. See Review deployment status and errors.

