Skip to content

Getting Started with the Integrations API

The integrations API is a REST API that allows you to integrate your remote data platform with Immuta so that Immuta can manage and enforce access controls on your data.

To configure an integration using the API, you must have the APPLICATION_ADMIN Immuta permission.

Authenticate with the API

graph LR
A(Authenticate) --> B(Configure integration) --> C(Map users and create policies) --> D(Register metadata);
style A fill:#2F6BA7,color:#fff
style B fill:#fff
style C fill:#fff
style D fill:#fff
click A "#authenticate-with-the-api" _blank
click B "#configure-your-integration" _blank
click C "#protect-your-data" _blank
click D "#register-metadata" _blank

There are two methods for making an authenticated request to the integrations API. Select a tab below for instructions.

API key method

  1. Generate your API key on the API Keys tab on your profile page and save the API key somewhere secure.
  2. You will pass this API key in the authorization header when you make a request, as illustrated in the example below:

    curl \
        --request GET \
        --header "Content-Type: application/json" \
        --header "Authorization: 846e9e43c86a4ct1be14290d95127d13f" \
        https://www.organization.immuta.com/integrations
    

Bearer token method

  1. Generate your API key on the API Keys tab on your profile page and save the API key somewhere secure.
  2. Save your API key in a .json file.

    {
    "apikey": "846e9e43c86a4ct1be14290d95127d13f"
    }
    
  3. Make the following request to the authentication endpoint:

    curl \
        --request POST \
        --header "Content-Type: application/json" \
        --data @example_payload.json \
        https://www.organization.immuta.com/bim/apikey/authenticate
    
  4. You will receive a response that includes your bearer token. Pass that bearer token in the Authorization header when you make a request, as illustrated in the example below:

    curl \
        --request GET \
        --header "Content-Type: application/json" \
        --header "Authorization: Bearer dea464c07bd07300095caa8" \
        https://demo.immuta.com/integrations
    

Configure your integration

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
click A "#authenticate-with-the-api" _blank
click B "#configure-your-integration" _blank
click C "#protect-your-data" _blank
click D "#register-metadata" _blank

Use the POST /integrations endpoint to configure the integration so that Immuta can enforce access controls on tables registered as Immuta data sources. Select a tab below to see a sample request and details about configuring your integration.

Private preview

The Amazon S3 integration is available to select accounts. Reach out to your Immuta representative for details.

Amazon S3 integration example request

  1. Set up an Access Grants instance.
  2. Copy the request example below.
  3. Replace the values in the request with your Immuta URL and API key or bearer token.
  4. Change the config values to your own, where

    • name is the name for the integration that is unique across all Amazon S3 integrations configured in Immuta.
    • awsAccountId is the ID of your AWS account.
    • awsRegion is the account's AWS region (such as us-east1).
    • awsLocationRole is the AWS IAM role ARN assigned to the base access grants location. This is the role the AWS Access Grants service assumes to vend credentials to the grantee.
    • awsLocationPath is the base S3 location prefix that Immuta will use for this connection when registering S3 data sources. This path must be unique across all S3 integrations configured in Immuta.
    • awsAccessKeyId is the AWS access key ID of the AWS account configuring the integration.
    • awsSecretAccessKey is the AWS secret access key of the AWS account configuring the integration.
curl -X 'POST' \
    'https://www.organization.immuta.com/integrations' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Native S3",
    "autoBootstrap": false,
    "config": {
      "name": "S3 integration",
      "awsAccountId": "123456789",
      "awsRegion": "us-east-1",
      "awsLocationRole": "arn:aws:iam::123456789:role/access-grants-instance-role",
      "awsLocationPath": "s3://",
      "authenticationType": "accessKey",
      "awsAccessKeyId": "123456789",
      "awsSecretAccessKey": "123456789"
    }
    }'

Azure Synapse Analytics integration example request

Replace the values in the request below with your Immuta URL and API key or bearer token, and change the config values to your own, where

  • host is the URL of your Azure Synapse Analytics account.
  • schema is the name of the Immuta-managed schema where all your secure views will be created and stored.
  • database is the name of an existing database where the Immuta system user will store all Immuta-generated schemas and views.
  • username and password are the username and password of the system account that can act on Azure Synapse Analytics objects and configure the integration.

The example below sets autoBootstrap to true, which grants Immuta one-time access to credentials to configure the resources in your Azure Synapse Analytics environment for you. If you set autoBootstrap to false, you must manually run the bootstrap script in your Azure Synapse Analytics environment yourself before making the request below.

curl -X 'POST' \
    'https://www.organization.immuta.com/integrations' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Azure Synapse Analytics",
    "autoBootstrap": true,
    "config": {
      "host": "organization.azure.com",
      "schema": "immuta",
      "database": "sample_database",
      "username": "taylor@synapse.com",
      "password": "abc1234"
    }
    }'

For more configuration examples, see the Configure an Azure Synapse Analytics integration guide. For information about the configuration payload, see the Integration payload reference guide.

Databricks Unity Catalog integration example request

Replace the values in the request below with your Immuta URL and API key or bearer token, and change the config values to your own, where

  • workspaceUrl is your Databricks workspace URL.
  • httpPath is the HTTP path of your Databricks cluster or SQL warehouse.
  • token is the Databricks personal access token. This is the access token for the Immuta system account user.
  • catalog is the name of the Databricks catalog Immuta will create to store internal entitlements and other user data specific to Immuta. This catalog will only be readable for the Immuta service principal and should not be granted to other users. The catalog name may only contain letters, numbers, and underscores and cannot start with a number.
curl -X 'POST' \
    'https://www.organization.immuta.com/integrations' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Databricks",
    "autoBootstrap": true,
    "config": {
      "workspaceUrl": "www.example-workspace.cloud.databricks.com",
      "httpPath": "sql/protocolv1/o/0/0000-00000-abc123",
      "authenticationType": "token",
      "token": "REDACTED",
      "catalog": "immuta"
    }
    }'

For more configuration examples, see the Configure a Databricks Unity Catalog integration guide. For information about the configuration payload, see the Integration payload reference guide.

Private preview

This integration is available to select accounts. Reach out to your Immuta representative for details.

Google BigQuery integration example request

  1. Create a Google Cloud service account and role by either using the Google Cloud console or the provided Immuta script.
  2. Copy the request example. The example uses JSON format, but the request also accepts YAML.
  3. Replace the Immuta URL and API key with your own.
  4. Change the config values to your own, where

    • role is the Google Cloud role used to connect to Google BigQuery.
    • datasetSuffix is the suffix to postfix to the name of each dataset created to store secure views. This string must start with an underscore.
    • dataset is the name of the BigQuery dataset to provision inside of the project for Immuta metadata storage.
    • location is the dataset's location, which can be any valid GCP location (such as us-east1).
    • credential is the Google BigQuery service account JSON keyfile credential content. See the Google documentation for guidance on generating and downloading this keyfile.
curl -X 'POST' \
    'https://www.organization.immuta.com/integrations' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Google BigQuery",
    "autoBootstrap": false,
    "config": {
        "role": "immuta",
        "datasetSuffix": "_secureView",
        "dataset": "immuta",
        "location": "us-east1",
        "credential": "{\"type\":\"service_account\",\"project_id\":\"innate-conquest-123456\",\"private_key_id\":\"9163c12345690924f5dd218ff39\",\"private_key\":\"-----BEGIN PRIVATE KEY-----\nXXXXXXXro0s\n/yQlPQijowkccmrmWJyr93kdLnwJzBvLHCto/+W\ncvF2ygX9oM/dyUK//z//4nptMp+Ck//Yw3D4rIBwGu4DWiR1qRnf\nDoGyXfThPTQ==\n-----END PRIVATE KEY-----\n\",\"client_email\":\"service-account-id@innate-conquest-123456.iam.gserviceaccount.com\",\"client_id\":\"1166290***432952487857\",\"auth_uri\":\"https://accounts.google.com/o/oauth2/auth\",\"token_uri\":\"https://oauth2.googleapis.com/token\",\"auth_provider_x509_cert_url\":\"https://www.googleapis.com/oauth2/v1/certs\",\"client_x509_cert_url\":\"https://www.googleapis.com/robot/v1/metadata/x509/service-accound-id%40innate-conquest-123456.iam.gserviceaccount.com\",\"universe_domain\":\"googleapis.com\"}"
    }
    }'

For more configuration examples, see the Configure a Google BigQuery integration guide. For information about the configuration payload, see the Integration payload reference guide.

Redshift integration example request

Replace the values in the request below with your Immuta URL and API key or bearer token, and change the config values to your own, where

  • host is the URL of your Redshift account.
  • database is the name of a new empty database that the Immuta system user will manage and store metadata in.
  • initialDatabase is the name of an existing database in Redshift that Immuta initially connects to and creates the Immuta-managed database.
  • authenticationType is the type of authentication to use when connecting to Redshift.
  • username and password are the credentials for the system account that can act on Redshift objects and configure the integration.

The example below sets autoBootstrap to true, which grants Immuta one-time access to credentials to configure the resources in your Redshift environment for you. If you set autoBootstrap to false, you must manually run the bootstrap script in your Redshift environment yourself before making the request below.

curl -X 'POST' \
    'https://www.organization.immuta.com/integrations' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
    -d '{
    "type": "Redshift",
    "autoBootstrap": true,
    "config": {
      "host": "organization.aws.amazon.com",
      "database": "immuta",
      "initialDatabase": "REDSHIFT_SAMPLE_DATA",
      "authenticationType": "userPassword",
      "username": "taylor@redshift.com",
      "password": "abc1234"
    }
    }'

For more configuration examples, see the Configure a Redshift integration guide. For information about the configuration payload, see the Integration payload reference guide.

Snowflake integration example request

Replace the values in the request below with your Immuta URL and API key or bearer token, and 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.
  • authenticationType is the type of authentication to use when connecting to Snowflake.
  • username and password are the credentials for the system account that can act on Snowflake objects and configure the integration.

The example below sets autoBootstrap to true, which grants Immuta one-time access to credentials to configure the resources in your Snowflake environment for you. If you set autoBootstrap to false, you must manually run the bootstrap script in your Snowflake environment yourself before making the request below.

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"
    }
    }'

For more configuration examples, see the Configure a Snowflake integration guide. For information about the configuration payload, see the Integration payload reference guide.

Starburst (Trino) integration example request

  1. Replace the values in the request below with your Immuta URL and API key or bearer token.

    curl -X 'POST' \
        'https://www.organization.immuta.com/integrations' \
        -H 'accept: application/json' \
        -H 'Content-Type: application/json' \
        -H 'Authorization: 846e9e43c86a4ct1be14290d95127d13f' \
        -d '{
        "type": "Trino"
        }'
    
  2. Navigate to the Immuta App Settings page and click the Integrations tab.

  3. Click your enabled Starburst (Trino) integration and copy the configuration snippet displayed.
  4. Follow the steps in the configure the Immuta system access control plugin in Trino section to add the configuration in the appropriate immuta-access-control.properties file to finish configuring your cluster.

Protect your data

graph LR
A(Authenticate) --> B(Configure integration) --> C(Map users and create policies) --> D(Register metadata);
style A fill:#fff
style B fill:#fff
style C fill:#2F6BA7,color:#fff
style D fill:#fff
click A "#authenticate-with-the-api" _blank
click B "#configure-your-integration" _blank
click C "#protect-your-data" _blank
click D "#register-metadata" _blank

Map usernames and create policies before you register your metadata to ensure that policies are enforced on tables and views immediately.

  1. Map usernames to Immuta to ensure Immuta properly enforces policies and audits user queries.
  2. Build global policies in Immuta to enforce access controls:

Register metadata

graph LR
A(Authenticate) --> B(Configure integration) --> C(Map users and create policies) --> D(Register metadata);
style A fill:#fff
style B fill:#fff
style C fill:#fff
style D fill:#2F6BA7,color:#fff
click A "#authenticate-with-the-api" _blank
click B "#configure-your-integration" _blank
click C "#protect-your-data" _blank
click D "#register-metadata" _blank

Register your metadata using the API or Immuta UI:

Additional resources

How-to guides

See the following how-to guides for configuration examples and steps for creating, managing, or disabling your integration:

Reference guides

See the following reference guides for information about the integrations API endpoints, payloads, and responses: