# Configure a Snowflake Integration

{% @mermaid/diagram content="graph LR
A(Authenticate) --> B(Configure integration) --> C(Map users and create policies) --> D(Register metadata);
style A fill:#fff
style B fill:#2F6BA7,color:#fff
style C fill:#fff
style D fill:#fff" %}

{% hint style="warning" %}
Support for this endpoint is only available using this legacy Snowflake workflow. [Use the /data endpoint for a Snowflake connection](https://documentation.immuta.com/saas/developer-guides/api-intro/connections-api/how-to-guides/register-a-connection/register-a-snowflake-connection).
{% endhint %}

In the Snowflake integration, Immuta manages access to Snowflake tables by administering Snowflake [row access policies](https://docs.snowflake.com/en/user-guide/security-row.html) and [column masking policies](https://docs.snowflake.com/en/user-guide/security-column.html) on those tables, allowing users to query tables directly in Snowflake while dynamic policies are enforced.

Use the `/integrations` endpoint to

* [configure a Snowflake integration](#configure-the-integration)
* [get a Snowflake integration](#get-an-integration)
* [get all integrations](#get-all-integrations)
* [update a Snowflake integration](#update-an-integration-configuration)
* [enable or edit impersonation for an existing integration](#enable-or-edit-impersonation-for-an-existing-integration)
* [delete a Snowflake integration](#delete-an-integration)

## Requirements

* `APPLICATION_ADMIN` Immuta permission
* The Snowflake user [running the installation, edit, or delete script](#user-content-fn-1)[^1] must have the following privileges:
  * `CREATE DATABASE ON ACCOUNT WITH GRANT OPTION`
  * `CREATE ROLE ON ACCOUNT WITH GRANT OPTION`
  * `CREATE USER ON ACCOUNT WITH GRANT OPTION`
  * `MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION`
  * `APPLY MASKING POLICY ON ACCOUNT WITH GRANT OPTION`
  * `APPLY ROW ACCESS POLICY ON ACCOUNT WITH GRANT OPTION`

## Configure the integration

You have two options for configuring your Snowflake integration:

* [**Automatic setup**](#automatic-setup): Grant Immuta one-time use of credentials to automatically configure your Snowflake environment and the integration. When performing an automated installation, Immuta requires temporary, one-time use of credentials with the Snowflake privileges listed in the [requirements section](#requirements).

  These privileges will be used to create and configure a new Immuta-managed database within the specified Snowflake instance. The credentials are not stored or saved by Immuta, and Immuta doesn’t retain access to them after initial setup is complete.

  You can create a new account for Immuta to use that has these privileges, or you can grant temporary use of a pre-existing account. By default, the pre-existing account with appropriate privileges is ACCOUNTADMIN. If you create a new account, it can be deleted after initial setup is complete.
* [**Manual setup**](#manual-setup): Run the Immuta script in your Snowflake environment yourself to configure your Snowflake environment and the integration. The specified role used to run the bootstrap needs to have the Snowflake privileges listed in the [requirements section](#requirements).

### Automatic setup

1. Select the section below that matches your authentication method.
2. Copy the request example and replace the values with your own as directed to configure the integration settings. The examples provided use JSON format, but the request also accepts YAML.

See the [**config** object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-configuration-objects) for parameter definitions, value types, and additional configuration options.

{% tabs %}
{% tab title="Username and password authentication" %}

```bash
curl -X 'POST' \
    'https://www.organization.immuta.com/integrations' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": true,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "authenticationType": "userPassword",
      "username": "taylor@snowflake.com",
      "password": "abc1234",
      "role": "ACCOUNTADMIN"
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Change the **config** values to your own, where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **username** and **password** are credentials of a [Snowflake account attached to a role with the privileges outlined above](#requirements). These credentials are not stored; they are used by Immuta to configure the integration.
   * **role** is a Snowflake role that has been granted the [privileges outlined above](#requirements).

Immuta will use the provided credentials to create a user called `IMMUTA_SYSTEM_ACCOUNT` and grant the following privileges to that user:

* `CREATE ROLE ON ACCOUNT WITH GRANT OPTION`
* `APPLY MASKING POLICY ON ACCOUNT WITH GRANT OPTION`
* `APPLY ROW ACCESS POLICY ON ACCOUNT WITH GRANT OPTION`
* `MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION`

Alternatively, you can use the [manual setup method](#manual-setup) and edit the provided script to grant the Immuta system account `OWNERSHIP` on the objects that Immuta will secure, instead of granting `MANAGE GRANTS ON ACCOUNT`. The current role that has `OWNERSHIP` on the securables will need to be granted to the Immuta system role. However, if granting `OWNERSHIP` instead of `MANAGE GRANTS ON ACCOUNT`, Immuta will not be able to manage the role that is granted to the account.
{% endtab %}

{% tab title="Snowflake key pair authentication" %}

```bash
curl -X 'POST' \
    'https://www.organization.immuta.com/integrations' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": true,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "authenticationType": "keyPair",
      "username": "SYSTEM_ACCOUNT",
      "privateKey": "-----BEGIN PRIVATE KEY-----\n<first line of private key content>\n<another line of private key content>\n<another line of private key content>\n-----END PRIVATE KEY-----"
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Change the **config** values to your own, where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **username** is the system account user that can assume the role to manage the database and administer Snowflake masking and row access policies.
   * **privateKey** is your private key. If you are using curl, replace new lines in the private key with a backslash before the new line character: "\n". If you are using another means of configuration, such as a Python script, the "\n" should not be added.
   * **connectArgs** is used to set `PRIV_KEY_FILE_PWD` if the private key is encrypted.

Immuta will use the provided credentials to create a user called `IMMUTA_SYSTEM_ACCOUNT` and grant the following privileges to that user:

* `CREATE ROLE ON ACCOUNT WITH GRANT OPTION`
* `APPLY MASKING POLICY ON ACCOUNT WITH GRANT OPTION`
* `APPLY ROW ACCESS POLICY ON ACCOUNT WITH GRANT OPTION`
* `MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION`

Alternatively, you can use the [manual setup method](#manual-setup) and edit the provided script to grant the Immuta system account `OWNERSHIP` on the objects that Immuta will secure, instead of granting `MANAGE GRANTS ON ACCOUNT`. The current role that has `OWNERSHIP` on the securables will need to be granted to the Immuta system role. However, if granting `OWNERSHIP` instead of `MANAGE GRANTS ON ACCOUNT`, Immuta will not be able to manage the role that is granted to the account.
{% endtab %}
{% endtabs %}

#### Response

The response returns the status of the Snowflake integration configuration connection. See the [response schema reference](https://documentation.immuta.com/saas/developer-guides/api-intro/integrations-api/reference-guides/response-schema) for details about the response schema.

{% tabs %}
{% tab title="200 response" %}
A successful response includes the validation tests statuses.

```json
{
  "id": "123456789",
  "status": "creating",
  "validationResults": {
    "status": "passed",
    "validationTests": [
    {
      "name": "Initial Validation: Basic Connection Test",
      "status": "passed"
    },
    {
      "name": "Initial Validation: Default Warehouse Access Test",
      "status": "passed",
      "result": []
    },
    {
      "name": "Initial Validation: Validate access to Privileged Role",
      "status": "passed",
      "result": []
    },
    {
      "name": "Validate Automatic: Database Does Not Exist",
      "status": "passed"
    },
    {
      "name": "Validate Automatic: Impersonation Role Does Not Exist",
      "status": "skipped"
    },
    {
      "name": "Validate Automatic Bootstrap User Grants",
      "status": "passed"
    }
    ]
  }
}
```

{% endtab %}

{% tab title="Unsuccessful request" %}
An unsuccessful request returns the status code and an error message. See the [HTTP status codes and error messages](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/status-codes#post-errors) for a list of statuses, error messages, and troubleshooting guidance.

```json
{
  "statusCode": 409,
  "error": "Conflict",
  "message": "Snowflake integration already exists on host organization.us-east-1.snowflakecomputing.com (id = 123456789)"
}
```

{% endtab %}
{% endtabs %}

### Manual setup

{% hint style="info" %}
**Best practices**

The account you create for Immuta should only be used for the integration and should not be used as the credentials for creating data sources in Immuta; doing so will cause issues. Instead, create a separate, dedicated READ-ONLY account for creating and registering data sources within Immuta.
{% endhint %}

To manually configure the integration, complete the following steps:

1. [Generate the Immuta script and run it in your Snowflake environment.](#generate-the-script)
2. [Configure the integration in Immuta.](#configure-the-integration-in-immuta)

#### Generate the script

1. Select the tab below that matches your authentication method.
2. Copy the request example and replace the values with your own as directed to generate the script. The examples provided use JSON format, but the request also accepts YAML.

See the [**config** object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-configuration-objects) for parameter definitions, value types, and additional configuration options.

{% tabs %}
{% tab title="Username and password" %}

```bash
curl -X 'POST' \
    'https://www.organization.immuta.com/integrations/scripts/create' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": false,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "audit": {
        "enabled": false,
      },
      "workspaces": {
        "enabled": false
      },
      "impersonation": {
        "enabled": false
      },
      "authenticationType": "userPassword",
      "username": "taylor@snowflake.com",
      "password": "abc1234"
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Change the **config** values to your own, where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
   * **workspaces** represents an Immuta project workspace configured for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#workspaces-object) for child parameters.
   * **impersonation** specifies whether user impersonation is enabled. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-impersonation-object) for child parameters. Once you finish configuring the integration, you can grant the `IMPERSONATE_USER` permission to Immuta users. See the [Managing users and permissions guide](https://documentation.immuta.com/saas/configuration/people/users-index/how-to-guides/managing-personas-and-permissions#add-permission-to-user) for instructions.
   * **username** and **password** are the credentials for the system account that can assume the role to manage the database and administer Snowflake masking and row access policies.
3. Run the script returned in the response in your Snowflake environment. Running this script grants the following privileges to the Immuta system account:

   * `CREATE ROLE ON ACCOUNT WITH GRANT OPTION`
   * `APPLY MASKING POLICY ON ACCOUNT WITH GRANT OPTION`
   * `APPLY ROW ACCESS POLICY ON ACCOUNT WITH GRANT OPTION`
   * `MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION`

   Alternatively, you can grant the Immuta system account `OWNERSHIP` on the objects that Immuta will secure, instead of granting `MANAGE GRANTS ON ACCOUNT`. The current role that has `OWNERSHIP` on the securables will need to be granted to the Immuta system role. However, if granting `OWNERSHIP` instead of `MANAGE GRANTS ON ACCOUNT`, Immuta will not be able to manage the role that is granted to the account, so it is recommended to run the script as-is, without changes.
   {% endtab %}

{% tab title="Snowflake key pair" %}

```bash
curl -X 'POST' \
    'https://www.organization.immuta.com/integrations/scripts/create' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": false,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "audit": {
        "enabled": false,
      },
      "workspaces": {
        "enabled": false
      },
      "impersonation": {
        "enabled": false
      },
      "authenticationType": "keyPair",
      "username": "SYSTEM_ACCOUNT",
      "privateKey": "-----BEGIN PRIVATE KEY-----\n<first line of private key content>\n<another line of private key content>\n<another line of private key content>\n-----END PRIVATE KEY-----"
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Change the **config** values to your own, where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
   * **workspaces** represents an Immuta project workspace configured for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#workspaces-object) for child parameters.
   * **impersonation** specifies whether user impersonation is enabled. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-impersonation-object) for child parameters. Once you finish configuring the integration, you can grant the `IMPERSONATE_USER` permission to Immuta users. See the [Managing users and permissions guide](https://documentation.immuta.com/saas/configuration/people/users-index/how-to-guides/managing-personas-and-permissions#add-permission-to-user) for instructions.
   * **username** is the system account user that can assume the role to manage the database and administer Snowflake masking and row access policies.
   * **privateKey** is your private key. If you are using curl, replace new lines in the private key with a backslash before the new line character: "\n". If you are using another means of configuration, such as a Python script, the "\n" should not be added.
   * **connectArgs** is used to set `PRIV_KEY_FILE_PWD` if the private key is encrypted.
3. Run the script returned in the response in your Snowflake environment. Running this script grants the following privileges to the Immuta system account:

   * `CREATE ROLE ON ACCOUNT WITH GRANT OPTION`
   * `APPLY MASKING POLICY ON ACCOUNT WITH GRANT OPTION`
   * `APPLY ROW ACCESS POLICY ON ACCOUNT WITH GRANT OPTION`
   * `MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION`

   Alternatively, you can grant the Immuta system account `OWNERSHIP` on the objects that Immuta will secure, instead of granting `MANAGE GRANTS ON ACCOUNT`. The current role that has `OWNERSHIP` on the securables will need to be granted to the Immuta system role. However, if granting `OWNERSHIP` instead of `MANAGE GRANTS ON ACCOUNT`, Immuta will not be able to manage the role that is granted to the account, so it is recommended to run the script as-is, without changes.
   {% endtab %}

{% tab title="Snowflake External OAuth" %}
In this example, Snowflake External OAuth is used to authenticate the system account user, ensuring secure communication between Immuta and Snowflake. To use this authentication method, `autoBootstrap` must be `false`.

```bash
curl -X 'POST' \
    'https://www.organization.immuta.com/integrations/scripts/create' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": false,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "impersonation": {
        "enabled": true,
        "role": "IMMUTA_IMPERSONATION"
      },
      "audit": {
        "enabled": false
      },
      "workspaces": {
        "enabled": true,
        "warehouses": ["SAMPLE_WAREHOUSE"]
      },
      "authenticationType": "oAuthClientCredentials",
      "oAuthClientConfig": {
        "provider": "Okta",
        "clientId": "123456abc",
        "useCertificate": false,
        "clientSecret": "secret",
        "authorityUrl": "example.authority.com"
      }
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Change the **config** values to your own, where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
   * **workspaces.enabled** specifies whether Immuta project workspaces are enabled for Snowflake.
   * **workspaces.warehouses** is a list of warehouses that workspace users have usage privileges on.
   * **impersonation** specifies whether user impersonation is enabled. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-impersonation-object) for child parameters. Once you finish configuring the integration, you can grant the `IMPERSONATE_USER` permission to Immuta users. See the [Managing users and permissions guide](https://documentation.immuta.com/saas/configuration/people/users-index/how-to-guides/managing-personas-and-permissions#add-permission-to-user) for instructions.
   * **username** is the system account user that can act on Snowflake objects and configure the integration.
   * **oAuthClientConfig** specifies your provider, client ID, client secret, authority URL, and your encoded public and private keys. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-oauth-configuration-object) for details about child parameters.
3. Run the script returned in the response in your Snowflake environment. Running this script grants the following privileges to the Immuta system account:

   * `CREATE ROLE ON ACCOUNT WITH GRANT OPTION`
   * `APPLY MASKING POLICY ON ACCOUNT WITH GRANT OPTION`
   * `APPLY ROW ACCESS POLICY ON ACCOUNT WITH GRANT OPTION`
   * `MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION`

   Alternatively, you can grant the Immuta system account `OWNERSHIP` on the objects that Immuta will secure, instead of granting `MANAGE GRANTS ON ACCOUNT`. The current role that has `OWNERSHIP` on the securables will need to be granted to the Immuta system role. However, if granting `OWNERSHIP` instead of `MANAGE GRANTS ON ACCOUNT`, Immuta will not be able to manage the role that is granted to the account, so it is recommended to run the script as-is, without changes.
   {% endtab %}
   {% endtabs %}

**Response**

The response returns the script for you to run in your environment.

#### Configure the integration in Immuta

1. Select the tab below that matches your authentication method.
2. Copy the request example and replace the values with your own as directed to configure the integration settings. The examples provided use JSON format, but the request also accepts YAML. The parameters and values you provide in this payload must match those you provided when [generating the script](#generate-the-script).

See the [**config** object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-configuration-objects) for parameter definitions, value types, and additional configuration options.

{% tabs %}
{% tab title="Username and password" %}

```bash
curl -X 'POST' \
    'https://www.organization.immuta.com/integrations' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": false,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "audit": {
        "enabled": false,
      },
      "workspaces": {
        "enabled": false
      },
      "impersonation": {
        "enabled": false
      },
      "authenticationType": "userPassword",
      "username": "taylor@snowflake.com",
      "password": "abc1234"
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Pass the same payload you sent when [generating the script](#generate-the-script), where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
   * **workspaces** represents an Immuta project workspace configured for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#workspaces-object) for child parameters.
   * **impersonation** specifies whether user impersonation is enabled. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-impersonation-object) for child parameters. Once you finish configuring the integration, you can grant the `IMPERSONATE_USER` permission to Immuta users. See the [Managing users and permissions guide](https://documentation.immuta.com/saas/configuration/people/users-index/how-to-guides/managing-personas-and-permissions#add-permission-to-user) for instructions.
   * **username** and **password** are the credentials for the system account that can assume the role to manage the database and administer Snowflake masking and row access policies.
     {% endtab %}

{% tab title="Snowflake key pair" %}

```bash
curl -X 'POST' \
    'https://www.organization.immuta.com/integrations' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": false,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "audit": {
        "enabled": false,
      },
      "workspaces": {
        "enabled": false
      },
      "impersonation": {
        "enabled": false
      },
      "authenticationType": "keyPair",
      "username": "SYSTEM_ACCOUNT",
      "privateKey": "-----BEGIN PRIVATE KEY-----\n<first line of private key content>\n<another line of private key content>\n<another line of private key content>\n-----END PRIVATE KEY-----"
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Pass the same payload you sent when [generating the script](#generate-the-script), where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
   * **workspaces** represents an Immuta project workspace configured for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#workspaces-object) for child parameters.
   * **impersonation** specifies whether user impersonation is enabled. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-impersonation-object) for child parameters. Once you finish configuring the integration, you can grant the `IMPERSONATE_USER` permission to Immuta users. See the [Managing users and permissions guide](https://documentation.immuta.com/saas/configuration/people/users-index/how-to-guides/managing-personas-and-permissions#add-permission-to-user) for instructions.
   * **username** is the system account user that can assume the role to manage the database and administer Snowflake masking and row access policies.
   * **privateKey** is your private key. If you are using curl, replace new lines in the private key with a backslash before the new line character: "\n". If you are using another means of configuration, such as a Python script, the "\n" should not be added.
   * **connectArgs** is used to set `PRIV_KEY_FILE_PWD` if the private key is encrypted.
     {% endtab %}

{% tab title="Snowflake External OAuth " %}
In this example, Snowflake External OAuth is used to authenticate the system account user, ensuring secure communication between Immuta and Snowflake. To use this authentication method, `autoBootstrap` must be `false`.

```bash
curl -X 'POST' \
    'https://www.organization.immuta.com/integrations' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": false,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "impersonation": {
        "enabled": true,
        "role": "IMMUTA_IMPERSONATION"
      },
      "workspaces": {
        "enabled": true,
        "warehouses": ["SAMPLE_WAREHOUSE"]
      },
      "authenticationType": "oAuthClientCredentials",
      "oAuthClientConfig": {
        "provider": "Okta",
        "clientId": "123456abc",
        "useCertificate": false,
        "clientSecret": "secret",
        "authorityUrl": "example.authority.com"
      }
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Pass the same payload you sent when [generating the script](#generate-the-script), where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **impersonation** specifies whether user impersonation is enabled. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-impersonation-object) for child parameters. Once you finish configuring the integration, you can grant the `IMPERSONATE_USER` permission to Immuta users. See the [Managing users and permissions guide](https://documentation.immuta.com/saas/configuration/people/users-index/how-to-guides/managing-personas-and-permissions#add-permission-to-user) for instructions.
   * **workspaces** specifies whether Immuta project workspaces are enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#workspaces-object) for details about child parameters.
   * **oAuthClientConfig** specifies your provider, client ID, client secret, authority URL, and your encoded public and private keys. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-oauth-configuration-object) for details about child parameters.
     {% endtab %}
     {% endtabs %}

#### Response

The response returns the status of the Snowflake integration configuration connection. See the [response schema reference](https://documentation.immuta.com/saas/developer-guides/api-intro/integrations-api/reference-guides/response-schema) for details about the response schema.

{% tabs %}
{% tab title="200 response" %}
A successful response includes the validation tests statuses.

```json
{
  "id": "123456789",
  "status": "creating",
  "validationResults": {
    "status": "passed",
    "validationTests": [
    {
      "name": "Initial Validation: Basic Connection Test",
      "status": "passed"
    },
    {
      "name": "Initial Validation: Default Warehouse Access Test",
      "status": "passed",
      "result": []
    },
    {
      "name": "Initial Validation: Validate access to Privileged Role",
      "status": "passed",
      "result": []
    },
    {
      "name": "Validate Automatic: Database Does Not Exist",
      "status": "passed"
    },
    {
      "name": "Validate Automatic: Impersonation Role Does Not Exist",
      "status": "skipped"
    },
    {
      "name": "Validate Automatic Bootstrap User Grants",
      "status": "passed"
    }
    ]
  }
}
```

{% endtab %}

{% tab title="Unsuccessful request" %}
An unsuccessful request returns the status code and an error message. See the [HTTP status codes and error messages](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/status-codes#post-errors) for a list of statuses, error messages, and troubleshooting guidance.

```json
{
  "statusCode": 409,
  "error": "Conflict",
  "message": "Snowflake integration already exists on host organization.us-east-1.snowflakecomputing.com (id = 123456789)"
}
```

{% endtab %}
{% endtabs %}

## Get an integration

```bash
curl -X 'GET' \
    'https://www.organization.immuta.com/integrations/{id}' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f'
```

1. Copy the request example.
2. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
3. Replace the **{id}** request parameter with the unique identifier of the integration you want to get. Alternatively, you can get a list of all integrations and their IDs with the [<mark style="color:blue;">`GET /integrations`</mark> <mark style="color:blue;">endpoint</mark>](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integrations-api#get-integrations).

### Response

The response returns the Snowflake integration configuration. See the [response schema reference](https://documentation.immuta.com/saas/developer-guides/api-intro/integrations-api/reference-guides/response-schema) for details about the response schema. An unsuccessful request returns the status code and an error message. See the [HTTP status codes and error messages](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/status-codes#get-error) for a list of statuses, error messages, and troubleshooting guidance.

{% tabs %}
{% tab title="Username and password authentication" %}

```json
{
  "id": "123456789",
  "status": "enabled",
  "validationResults": {
    "status": "passed",
    "validationTests": [
    {
      "name": "Initial Validation: Basic Connection Test",
      "status": "passed"
    },
    {
      "name": "Initial Validation: Default Warehouse Access Test",
      "status": "passed",
      "result": []
    },
    {
      "name": "Initial Validation: Validate access to Privileged Role",
      "status": "passed",
      "result": []
    },
    {
      "name": "Validate Automatic: Database Does Not Exist",
      "status": "passed"
    },
    {
      "name": "Validate Automatic: Impersonation Role Does Not Exist",
      "status": "skipped"
    },
    {
      "name": "Validate Automatic Bootstrap User Grants",
      "status": "passed"
    }
    ]
  },
  "type": "Snowflake",
  "autoBootstrap": true,
  "config": {
    "host": "organization.us-east-1.snowflakecomputing.com",
    "warehouse": "SAMPLE_WAREHOUSE",
    "database": "SNOWFLAKE_SAMPLE_DATA",
    "port": 443,
    "audit": {
      "enabled": false,
      },
    "workspaces": {
      "enabled": false
    },
    "impersonation": {
      "enabled": false
    },
    "lineage": {
      "enabled": false
    },
    "authenticationType": "userPassword",
    "username": "<REDACTED>",
    "password": "<REDACTED>",
    "role": "ACCOUNTADMIN"
  }
}
```

{% endtab %}

{% tab title="Snowflake External OAuth authentication" %}

```json
{
  "id": "123456789",
  "status": "enabled",
  "validationResults": {
    "status": "passed",
    "validationTests": [
    {
      "name": "Initial Validation: Basic Connection Test",
      "status": "passed"
    },
    {
      "name": "Initial Validation: Default Warehouse Access Test",
      "status": "passed",
      "result": []
    },
    {
      "name": "Initial Validation: Validate access to Privileged Role",
      "status": "passed",
      "result": []
    },
    {
      "name": "Validate Automatic: Database Does Not Exist",
      "status": "passed"
    },
    {
      "name": "Validate Automatic: Impersonation Role Does Not Exist",
      "status": "skipped"
    },
    {
      "name": "Validate Automatic Bootstrap User Grants",
      "status": "passed"
    }
    ]
  },
  "type": "Snowflake",
  "autoBootstrap": false,
  "config": {
    "host": "organization.us-east-1.snowflakecomputing.com",
    "warehouse": "SAMPLE_WAREHOUSE",
    "database": "SNOWFLAKE_SAMPLE_DATA",
    "port": 443,
    "impersonation": {
      "enabled": true,
      "role": "IMMUTA_IMPERSONATION"
    },
    "audit": {
      "enabled": false
    },
    "workspaces": {
      "enabled": true,
      "warehouses": ["SAMPLE_WAREHOUSE"]
    },
    "lineage": {
      "enabled": false
    },
    "authenticationType": "oAuthClientCredentials",
    "oAuthClientConfig": {
      "provider": "Okta",
      "clientId": "123456abc",
      "useCertificate": false,
      "clientSecret": "secret",
      "authorityUrl": "example.authority.com"
    }
  }
}
```

{% endtab %}
{% endtabs %}

## Get all integrations

1. Copy the request example.
2. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.

```bash
curl -X 'GET' \
    'https://www.organization.immuta.com/integrations' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f'
```

### Response

The response returns the configuration for all integrations. See the [response schema reference](https://documentation.immuta.com/saas/developer-guides/api-intro/integrations-api/reference-guides/response-schema) for details about the response schema. An unsuccessful request returns the status code and an error message. See the [HTTP status codes and error messages](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/status-codes#get-error) for a list of statuses, error messages, and troubleshooting guidance.

```json
[
  {
    "id": "1",
    "status": "enabled",
    "validationResults": {
      "status": "passed",
      "validationTests": [
        {
          "name": "Initial Validation: Basic Connection Test",
          "status": "passed"
        },
        {
          "name": "Initial Validation: Default Warehouse Access Test",
          "status": "passed",
          "result": []
        },
        {
          "name": "Initial Validation: Validate access to Privileged Role",
          "status": "passed",
          "result": []
        },
        {
          "name": "Validate Automatic: Database Does Not Exist",
          "status": "passed"
        },
        {
          "name": "Validate Automatic: Impersonation Role Does Not Exist",
          "status": "skipped"
        },
        {
          "name": "Validate Automatic Bootstrap User Grants",
          "status": "passed"
        }
      ]
    },
    "type": "Snowflake",
    "autoBootstrap": true,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "port": 443,
      "audit": {
        "enabled": false
      },
      "workspaces": {
        "enabled": false
      },
      "impersonation": {
        "enabled": false
      },
      "lineage": {
        "enabled": false
      },
      "authenticationType": "userPassword",
      "username": "<REDACTED>",
      "password": "<REDACTED>",
      "role": "ACCOUNTADMIN"
    }
  },
  {
    "id": "2",
    "status": "enabled",
    "type": "Databricks",
    "validationResults": {
      "status": "passed",
      "validationTests": [
        {
          "name": "Metastore validation",
          "status": "passed"
        },
        {
          "name": "Basic Connection Test",
          "result": [
            {
              "1": 1
            }
          ],
          "status": "passed"
        }
      ]
    },
    "autoBootstrap": true,
    "config": {
      "workspaceUrl": "www.example-workspace.cloud.databricks.com",
      "httpPath": "sql/protocolv1/o/0/0000-00000-abc123",
      "token": "REDACTED",
      "audit": {
        "enabled": false
      },
      "catalog": "immuta"
    }
  }
]
```

## Update an integration configuration

You have two options for updating your integration. Follow the steps that match your initial configuration of **autoBootstrap**:

* [**automatic update**](#automatic-update) (**autoBootstrap** is `true`)
* [**manual update**](#manual-update) (**autoBootstrap** is `false`)

### Automatic update

1. Select the section below that matches your authentication method.
2. Copy the request example and replace the values with your own as directed to update the integration settings. The examples provided use JSON format, but the request also accepts YAML.

See the [**config** object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-configuration-objects) for parameter definitions, value types, and additional configuration options.

{% tabs %}
{% tab title="Username and password authentication" %}
This request updates the configuration to enable query audit in Snowflake.

```bash
curl -X 'PUT' \
    'https://www.organization.immuta.com/integrations/{id}' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": true,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "audit": {
        "enabled": true,
      },
      "authenticationType": "userPassword",
      "username": "taylor@snowflake.com",
      "password": "abc1234",
      "role": "ACCOUNTADMIN"
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Replace the **{id}** request parameter with the unique identifier of the integration you want to update.
3. Change the **config** values to your own, where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
   * **username** and **password** are credentials of a [Snowflake account attached to a role with the privileges outlined above](#requirements). These credentials are not stored; they are used by Immuta to enable or disable configuration settings.
   * **role** is a Snowflake role that has been granted the [privileges outlined above](#requirements).
     {% endtab %}

{% tab title="Snowflake key pair authentication" %}
This request updates the configuration to enable query audit in Snowflake.

```bash
curl -X 'PUT' \
    'https://www.organization.immuta.com/integrations/{id}' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": true,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "audit": {
        "enabled": true
      },
      "authenticationType": "keyPair",
      "username": "SYSTEM_ACCOUNT",
      "privateKey": "-----BEGIN PRIVATE KEY-----\n<first line of private key content>\n<another line of private key content>\n<another line of private key content>\n-----END PRIVATE KEY-----"
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Replace the **{id}** request parameter with the unique identifier of the integration you want to update.
3. Change the **config** values to your own, where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
   * **username** is the system account user that can assume the role to manage the database and administer Snowflake masking and row access policies.
   * **privateKey** is your private key. If you are using curl, replace new lines in the private key with a backslash before the new line character: "\n". If you are using another means of configuration, such as a Python script, the "\n" should not be added.
   * **connectArgs** is used to set `PRIV_KEY_FILE_PWD` if the private key is encrypted.
     {% endtab %}
     {% endtabs %}

#### Response

The response returns the status of the Snowflake integration configuration. See the [response schema reference](https://documentation.immuta.com/saas/developer-guides/api-intro/integrations-api/reference-guides/response-schema) for details about the response schema.

{% tabs %}
{% tab title="200 response" %}
A successful response includes the validation tests statuses.

```json
{
  "id": "123456789",
  "status": "editing",
  "validationResults": {
    "status": "passed",
    "validationTests": [
    {
      "name": "Initial Validation: Basic Connection Test",
      "status": "passed"
    },
    {
      "name": "Initial Validation: Default Warehouse Access Test",
      "status": "passed",
      "result": []
    },
    {
      "name": "Initial Validation: Validate access to Privileged Role",
      "status": "passed",
      "result": []
    },
    {
      "name": "Validate Automatic: Database Does Not Exist",
      "status": "passed"
    },
    {
      "name": "Validate Automatic: Impersonation Role Does Not Exist",
      "status": "skipped"
    },
    {
      "name": "Validate Automatic Bootstrap User Grants",
      "status": "passed"
    }
    ]
  }
}
```

{% endtab %}

{% tab title="Unsuccessful request" %}
An unsuccessful request returns the status code and an error message. See the [HTTP status codes and error messages](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/status-codes#put-errors) for a list of statuses, error messages, and troubleshooting guidance.

```json
{
  "statusCode": 409,
  "error": "Conflict",
  "message": "Unable to edit integration with ID 123456789 in current state editing."
}
```

{% endtab %}
{% endtabs %}

### Manual update

To manually update the integration, complete the following steps:

1. [Generate the updated Immuta script and run it in your Snowflake environment.](#generate-the-updated-script)
2. [Update the integration in Immuta.](#update-the-integration-in-immuta)

#### Generate the updated script

1. Select the tab below that matches your authentication method.
2. Copy the request example and replace the values with your own as directed to generate the script. The examples provided use JSON format, but the request also accepts YAML.

See the [**config** object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-configuration-objects) for parameter definitions, value types, and additional configuration options.

{% tabs %}
{% tab title="Username and password" %}
This request updates the configuration to enable query audit in Snowflake.

```bash
curl -X 'POST' \
    'https://www.organization.immuta.com/integrations/{id}/scripts/edit' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": false,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "audit": {
        "enabled": true
      },
      "workspaces": {
        "enabled": false
      },
      "impersonation": {
        "enabled": false
      },
      "authenticationType": "userPassword",
      "username": "taylor@snowflake.com",
      "password": "abc1234"
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Replace the **{id}** request parameter with the unique identifier of the integration you want to update.
3. Change the **config** values to your own, where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
   * **workspaces** represents an Immuta project workspace configured for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#workspaces-object) for child parameters.
   * **impersonation** specifies whether user impersonation is enabled. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-impersonation-object) for child parameters. Once you finish configuring the integration, you can grant the `IMPERSONATE_USER` permission to Immuta users. See the [Managing users and permissions guide](https://documentation.immuta.com/saas/configuration/people/users-index/how-to-guides/managing-personas-and-permissions#add-permission-to-user) for instructions.
   * **username** and **password** are the credentials for the system account that can assume the role to manage the database and administer Snowflake masking and row access policies.
4. Run the script returned in the response in your Snowflake environment.
   {% endtab %}

{% tab title="Snowflake key pair" %}
This request updates the configuration to enable query audit in Snowflake.

```bash
curl -X 'POST' \
    'https://www.organization.immuta.com/integrations/{id}/scripts/edit' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": false,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "audit": {
        "enabled": true
      },
      "workspaces": {
        "enabled": false
      },
      "impersonation": {
        "enabled": false
      },
      "authenticationType": "keyPair",
      "username": "SYSTEM_ACCOUNT",
      "privateKey": "-----BEGIN PRIVATE KEY-----\n<first line of private key content>\n<another line of private key content>\n<another line of private key content>\n-----END PRIVATE KEY-----"
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Replace the **{id}** request parameter with the unique identifier of the integration you want to update.
3. Change the **config** values to your own, where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
   * **workspaces** represents an Immuta project workspace configured for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#workspaces-object) for child parameters.
   * **impersonation** specifies whether user impersonation is enabled. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-impersonation-object) for child parameters. Once you finish configuring the integration, you can grant the `IMPERSONATE_USER` permission to Immuta users. See the [Managing users and permissions guide](https://documentation.immuta.com/saas/configuration/people/users-index/how-to-guides/managing-personas-and-permissions#add-permission-to-user) for instructions.
   * **username** is the system account user that can assume the role to manage the database and administer Snowflake masking and row access policies.
   * **privateKey** is your private key. If you are using curl, replace new lines in the private key with a backslash before the new line character: "\n". If you are using another means of configuration, such as a Python script, the "\n" should not be added.
   * **connectArgs** is used to set `PRIV_KEY_FILE_PWD` if the private key is encrypted.
4. Run the script returned in the response in your Snowflake environment.
   {% endtab %}

{% tab title="Snowflake External OAuth" %}
This request updates the configuration to disable Snowflake workspaces for the integration.

```bash
curl -X 'POST' \
    'https://www.organization.immuta.com/integrations/{id}/scripts/edit' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": false,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "impersonation": {
        "enabled": true,
        "role": "IMMUTA_IMPERSONATION"
      },
      "audit": {
        "enabled": true
      },
      "workspaces": {
        "enabled": false
      },
      "authenticationType": "oAuthClientCredentials",
      "oAuthClientConfig": {
        "provider": "Okta",
        "clientId": "123456abc",
        "useCertificate": false,
        "clientSecret": "secret",
        "authorityUrl": "example.authority.com"
      }
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Replace the **{id}** request parameter with the unique identifier of the integration you want to update.
3. Change the **config** values to your own, where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
   * **workspaces** represents an Immuta project workspace configured for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#workspaces-object) for child parameters.
   * **impersonation** specifies whether user impersonation is enabled. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-impersonation-object) for child parameters. Once you finish configuring the integration, you can grant the `IMPERSONATE_USER` permission to Immuta users. See the [Managing users and permissions guide](https://documentation.immuta.com/saas/configuration/people/users-index/how-to-guides/managing-personas-and-permissions#add-permission-to-user) for instructions.
   * **username** is the system account user that can act on Snowflake objects and configure the integration.
   * **oAuthClientConfig** specifies your provider, client ID, client secret, authority URL, and your encoded public and private keys. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-oauth-configuration-object) for details about child parameters.
4. Run the script returned in the response in your Snowflake environment.
   {% endtab %}
   {% endtabs %}

**Response**

The response returns the script for you to run in your environment.

#### Update the integration in Immuta

1. Select the section below that matches your authentication method.
2. Copy the request example and replace the values with your own as directed to update the integration settings. The examples provided use JSON format, but the request also accepts YAML. The payload you provide must match the one you provided when [generating the updated script](#generate-the-updated-script).

See the [**config** object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-configuration-objects) for parameter definitions, value types, and additional configuration options.

{% tabs %}
{% tab title="Username and password" %}
This request updates the configuration to enable query audit in Snowflake.

```bash
curl -X 'PUT' \
    'https://www.organization.immuta.com/integrations/{id}' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": false,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "audit": {
        "enabled": true
      },
      "workspaces": {
        "enabled": false
      },
      "impersonation": {
        "enabled": false
      },
      "authenticationType": "userPassword",
      "username": "taylor@snowflake.com",
      "password": "abc1234"
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Replace the **{id}** request parameter with the unique identifier of the integration you want to update.
3. Pass the same payload you sent when [generating the script](#generate-the-updated-script), where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
   * **workspaces** represents an Immuta project workspace configured for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#workspaces-object) for child parameters.
   * **impersonation** specifies whether user impersonation is enabled. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-impersonation-object) for child parameters. Once you finish configuring the integration, you can grant the `IMPERSONATE_USER` permission to Immuta users. See the [Managing users and permissions guide](https://documentation.immuta.com/saas/configuration/people/users-index/how-to-guides/managing-personas-and-permissions#add-permission-to-user) for instructions.
   * **username** and **password** are the credentials for the system account that can assume the role to manage the database and administer Snowflake masking and row access policies.
     {% endtab %}

{% tab title="Snowflake key pair" %}
This request updates the configuration to enable query audit in Snowflake.

```bash
curl -X 'PUT' \
    'https://www.organization.immuta.com/integrations/{id}' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": false,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "audit": {
        "enabled": true
      },
      "workspaces": {
        "enabled": false
      },
      "impersonation": {
        "enabled": false
      },
      "authenticationType": "keyPair",
      "username": "SYSTEM_ACCOUNT",
      "privateKey": "-----BEGIN PRIVATE KEY-----\n<first line of private key content>\n<another line of private key content>\n<another line of private key content>\n-----END PRIVATE KEY-----"
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Replace the **{id}** request parameter with the unique identifier of the integration you want to update.
3. Pass the same payload you sent when [generating the script](#generate-the-updated-script), where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
   * **workspaces** represents an Immuta project workspace configured for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#workspaces-object) for child parameters.
   * **impersonation** specifies whether user impersonation is enabled. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-impersonation-object) for child parameters. Once you finish configuring the integration, you can grant the `IMPERSONATE_USER` permission to Immuta users. See the [Managing users and permissions guide](https://documentation.immuta.com/saas/configuration/people/users-index/how-to-guides/managing-personas-and-permissions#add-permission-to-user) for instructions.
   * **username** is the system account user that can assume the role to manage the database and administer Snowflake masking and row access policies.
   * **privateKey** is your private key. If you are using curl, replace new lines in the private key with a backslash before the new line character: "\n". If you are using another means of configuration, such as a Python script, the "\n" should not be added.
   * **connectArgs** is used to set `PRIV_KEY_FILE_PWD` if the private key is encrypted.
     {% endtab %}

{% tab title="Snowflake External OAuth" %}
This request updates the configuration to disable Snowflake workspaces and enable Snowflake query audit for the integration.

```bash
curl -X 'PUT' \
    'https://www.organization.immuta.com/integrations/{id}' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Snowflake",
    "autoBootstrap": false,
    "config": {
      "host": "organization.us-east-1.snowflakecomputing.com",
      "warehouse": "SAMPLE_WAREHOUSE",
      "database": "SNOWFLAKE_SAMPLE_DATA",
      "impersonation": {
        "enabled": true,
        "role": "IMMUTA_IMPERSONATION"
      },
      "audit": {
        "enabled": true
      },
      "workspaces": {
        "enabled": false
      },
      "authenticationType": "oAuthClientCredentials",
      "oAuthClientConfig": {
        "provider": "Okta",
        "clientId": "123456abc",
        "useCertificate": false,
        "clientSecret": "secret",
        "authorityUrl": "example.authority.com"
      }
    }
    }'
```

1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
2. Replace the **{id}** request parameter with the unique identifier of the integration you want to update.
3. Pass the same payload you sent when [generating the script](#generate-the-updated-script), where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **impersonation** specifies whether user impersonation is enabled. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-impersonation-object) for child parameters. Once you finish configuring the integration, you can grant the `IMPERSONATE_USER` permission to Immuta users. See the [Managing users and permissions guide](https://documentation.immuta.com/saas/configuration/people/users-index/how-to-guides/managing-personas-and-permissions#add-permission-to-user) for instructions.
   * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
   * **workspaces** specifies whether Immuta project workspaces are enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#workspaces-object) for details about child parameters.
   * **oAuthClientConfig** specifies your provider, client ID, client secret, authority URL, and your encoded public and private keys. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-oauth-configuration-object) for details about child parameters.
     {% endtab %}
     {% endtabs %}

#### Response

The response returns the status of the Snowflake integration configuration. See the [response schema reference](https://documentation.immuta.com/saas/developer-guides/api-intro/integrations-api/reference-guides/response-schema) for details about the response schema.

{% tabs %}
{% tab title="200 response" %}
A successful response includes the validation tests statuses.

```json
{
  "id": "123456789",
  "status": "editing",
  "validationResults": {
    "status": "passed",
    "validationTests": [
    {
      "name": "Initial Validation: Basic Connection Test",
      "status": "passed"
    },
    {
      "name": "Initial Validation: Default Warehouse Access Test",
      "status": "passed",
      "result": []
    },
    {
      "name": "Initial Validation: Validate access to Privileged Role",
      "status": "passed",
      "result": []
    },
    {
      "name": "Validate Automatic: Database Does Not Exist",
      "status": "passed"
    },
    {
      "name": "Validate Automatic: Impersonation Role Does Not Exist",
      "status": "skipped"
    },
    {
      "name": "Validate Automatic Bootstrap User Grants",
      "status": "passed"
    }
    ]
  }
}
```

{% endtab %}

{% tab title="Unsuccessful request" %}
An unsuccessful request returns the status code and an error message. See the [HTTP status codes and error messages](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/status-codes#put-errors) for a list of statuses, error messages, and troubleshooting guidance.

```json
{
  "statusCode": 409,
  "error": "Conflict",
  "message": "Unable to edit integration with ID 123456789 in current state editing."
}
```

{% endtab %}
{% endtabs %}

### Enable or edit impersonation for an existing integration

You can enable impersonation for an existing Snowflake integration or edit the impersonation role name for an existing integration. Select one of the tabs below for guidance.

{% tabs %}
{% tab title="Enable impersonation" %}

1. If enabling impersonation for the first time, create the impersonation role in Snowflake:<br>

   ```sql
   CREATE ROLE "YOUR IMPERSONATION ROLE NAME";
   GRANT OWNERSHIP ON ROLE "YOUR IMPERSONATION ROLE NAME" TO ROLE "SYSTEM ACCOUNT ROLE";
   ```
2. Update the integration:<br>

   ```shellscript
   curl -X 'PUT' \
       'https://www.organization.immuta.com/integrations/{id}' \
       -H 'accept: application/json' \
       -H 'Content-Type: application/json' \
       -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
       -d '{
       "type": "Snowflake",
       "autoBootstrap": false,
       "config": {
         "host": "organization.us-east-1.snowflakecomputing.com",
         "warehouse": "SAMPLE_WAREHOUSE",
         "database": "SNOWFLAKE_SAMPLE_DATA",
         "audit": {
           "enabled": true
         },
         "workspaces": {
           "enabled": false
         },
         "impersonation": {
           "enabled": true,
           "role": "IMPERSONATION_ROLE"
         },
         "authenticationType": "userPassword",
         "username": "taylor@snowflake.com",
         "password": "abc1234"
       }
       }'
   ```

   1. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
   2. Replace the **{id}** request parameter with the unique identifier of the integration you want to update.
   3. Pass the same payload you sent when [generating the script](#generate-the-updated-script), where
      * **host** is the URL of your Snowflake account.
      * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
      * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
      * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
      * **workspaces** represents an Immuta project workspace configured for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#workspaces-object) for child parameters.
      * **impersonation.enabled** specifies whether user impersonation is enabled.
      * **impersonation.role** is the name of the Snowflake role that will be used to impersonate other users. This should match the name of the role you created in Snowflake in the previous step.
      * **username** and **password** are the credentials for the system account that can assume the role to manage the database and administer Snowflake masking and row access policies.

Once you finish configuring the integration, you can grant the `IMPERSONATE_USER` permission to Immuta users. See the [Managing users and permissions guide](https://documentation.immuta.com/saas/configuration/people/users-index/how-to-guides/managing-personas-and-permissions#add-permission-to-user) for instructions.
{% endtab %}

{% tab title="Edit an existing impersonation role name" %}

1. Copy the request below and update the **impersonation**.**role** in the integration configuration:<br>

   ```shellscript
   curl -X 'PUT' \
       'https://www.organization.immuta.com/integrations/{id}' \
       -H 'accept: application/json' \
       -H 'Content-Type: application/json' \
       -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
       -d '{
       "type": "Snowflake",
       "autoBootstrap": false,
       "config": {
         "host": "organization.us-east-1.snowflakecomputing.com",
         "warehouse": "SAMPLE_WAREHOUSE",
         "database": "SNOWFLAKE_SAMPLE_DATA",
         "audit": {
           "enabled": true
         },
         "workspaces": {
           "enabled": false
         },
         "impersonation": {
           "enabled": true,
           "role": "IMPERSONATION_ROLE"
         },
         "authenticationType": "userPassword",
         "username": "taylor@snowflake.com",
         "password": "abc1234"
       }
       }'
   ```
2. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
3. Replace the **{id}** request parameter with the unique identifier of the integration you want to update.
4. Pass the same payload you sent when [generating the script](#generate-the-updated-script), where
   * **host** is the URL of your Snowflake account.
   * **warehouse** is the default pool of Snowflake compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
   * **database** is the name of a new empty database that the Immuta system user will manage and store metadata in.
   * **audit** specifies whether query audit is enabled for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#audit-object) for child parameters.
   * **workspaces** represents an Immuta project workspace configured for Snowflake. See the [object description](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#workspaces-object) for child parameters.
   * **impersonation.enabled** specifies whether user impersonation is enabled.
   * **impersonation.role** is the name of the Snowflake role that will be used to impersonate other users.
   * **username** and **password** are the credentials for the system account that can assume the role to manage the database and administer Snowflake masking and row access policies.

Once you finish configuring the integration, you can grant the `IMPERSONATE_USER` permission to Immuta users. See the [Managing users and permissions guide](https://documentation.immuta.com/saas/configuration/people/users-index/how-to-guides/managing-personas-and-permissions#add-permission-to-user) for instructions.
{% endtab %}
{% endtabs %}

#### Response

The response returns the status of the Snowflake integration configuration. See the [response schema reference](https://documentation.immuta.com/saas/developer-guides/api-intro/integrations-api/reference-guides/response-schema) for details about the response schema.

{% tabs %}
{% tab title="200 response" %}
A successful response includes the validation tests statuses.

```json
{
  "id": "123456789",
  "status": "editing",
  "validationResults": {
    "status": "passed",
    "validationTests": [
    {
      "name": "Initial Validation: Basic Connection Test",
      "status": "passed"
    },
    {
      "name": "Initial Validation: Default Warehouse Access Test",
      "status": "passed",
      "result": []
    },
    {
      "name": "Initial Validation: Validate access to Privileged Role",
      "status": "passed",
      "result": []
    },
    {
      "name": "Validate Automatic: Database Does Not Exist",
      "status": "passed"
    },
    {
      "name": "Validate Automatic: Impersonation Role Does Not Exist",
      "status": "skipped"
    },
    {
      "name": "Validate Automatic Bootstrap User Grants",
      "status": "passed"
    }
    ]
  }
}
```

{% endtab %}

{% tab title="Unsuccessful request" %}
An unsuccessful request returns the status code and an error message. See the [HTTP status codes and error messages](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/status-codes#put-errors) for a list of statuses, error messages, and troubleshooting guidance.

```json
{
  "statusCode": 409,
  "error": "Conflict",
  "message": "Unable to edit integration with ID 123456789 in current state editing."
}
```

{% endtab %}
{% endtabs %}

## Delete an integration

```bash
curl -X 'DELETE' \
    'https://www.organization.immuta.com/integrations/{id}' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "authenticationType": "userPassword",
    "username": "taylor@snowflake.com",
    "password": "abc1234",
    "role": "ACCOUNTADMIN"
    }'
```

1. Copy the request example.
2. Replace the **Immuta URL** and [**API key**](https://documentation.immuta.com/saas/developer-guides/api-intro/getting-started#authenticate-with-the-api) with your own.
3. Replace the **{id}** request parameter with the unique identifier of the integration you want to delete.
4. If you set
   * **autoBootstrap** to `true` when enabling the integration, specify the [**authenticationType**](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integration-configuration-payload#snowflake-configuration-objects) and the credentials you used to configure the integration in the payload, as illustrated in the example. See the [Integrations API endpoints guide](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integrations-api#delete-integrations-id) for details.
   * **autoBootstrap** to `false` when enabling the integration,
5. Use the script [cleanup](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integrations-api#post-integrations-scripts-cleanup) endpoint (for integrations that were not successfully created) or the [delete](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/integrations-api#post-integrations-id-scripts-delete) endpoint (for integrations that were successfully created) to generate a script that will remove Immuta-managed resources and policies from your environment.
6. Make the request above without including a payload to remove the integration from Immuta.
7. Run the generated script in Snowflake.

{% hint style="warning" %}
**Cleaning up your Snowflake environment**\
Until you manually run the cleanup script in your Snowflake environment, Immuta-managed [roles](https://documentation.immuta.com/saas/configuration/integrations/snowflake/reference-guides/table-grants-overview#table-grants-role) and Immuta policies will still exist in Snowflake.
{% endhint %}

### Response

The response returns the status of the Snowflake integration configuration that has been deleted. See the [response schema reference](https://documentation.immuta.com/saas/developer-guides/api-intro/integrations-api/reference-guides/response-schema) for details about the response schema. An unsuccessful request returns the status code and an error message. See the [HTTP status codes and error messages](https://documentation.immuta.com/saas/developer-guides/api-intro/reference-guides/status-codes#delete-errors) for a list of statuses, error messages, and troubleshooting guidance.

```json
{
  "id": "123456789",
  "status": "deleting",
  "validationResults": {
    "status": "passed",
    "validationTests": [
    {
      "name": "Initial Validation: Basic Connection Test",
      "status": "passed"
    },
    {
      "name": "Initial Validation: Default Warehouse Access Test",
      "status": "passed",
      "result": []
    },
    {
      "name": "Initial Validation: Validate access to Privileged Role",
      "status": "passed",
      "result": []
    },
    {
      "name": "Validate Automatic: Database Does Not Exist",
      "status": "passed"
    },
    {
      "name": "Validate Automatic: Impersonation Role Does Not Exist",
      "status": "skipped"
    },
    {
      "name": "Validate Automatic Bootstrap User Grants",
      "status": "passed"
    }
    ]
  }
}
```

[^1]: If configuring the integration using the [automatic setup method](#automatic-setup), the credentials provided must have these privileges.