Version 2 API

Policy as code benefits

• Reduces complexity: The data source API has been simplified to only require the connection information in most instances and one endpoint for all database technologies.

• Maintains less state: Whether updating or creating, the same endpoint is used, and the same data is passed. No ids are required, so no additional state is required.

• Requires fewer steps: Only an API key is required; no additional authentication step is required before using the API.

• Integrates with Git: Define data sources and policies in files that can be tracked in Git and easily pushed to Immuta. Both JSON and YAML are supported for more flexibility. (For example, use YAML to add comments in files.)

Authentication

Before using the Immuta API, users need to authenticate with an API key. To generate an API key, complete the following steps in the Immuta UI.

1. Click your initial in the top right corner of the screen and select Profile.

2. Go to the API Keys tab and then click Generate Key.

3. Complete the required fields in the modal and click Create.

4. Pass the key that is provided in the Authorization header:

   curl --data-binary project.yaml -H "Authorization: ${IMMUTA_API_KEY}" -H "Content-Type: text/plain" https:/<immuta-url>/api/v2/project

Endpoints and details

All of the API endpoints described below take either JSON or YAML, and the endpoint and payload are the same for both creating and updating data sources, policies, projects, and purposes.

Create a data source

The V2 API is built to easily enable an “as-code” approach to managing your data sources, so each time you POST data to this endpoint, you are expected to provide complete details of what you want in Immuta. The two examples below illustrate this design:

• If you POST once explicitly defining a single table under sources, and then POST a second time with a different table, this will result in a single data source in Immuta pointing to the second table and the first data source will be deleted or disabled (depending on the value specified for hardDelete).

• If you POST once with two tableTags specified (e.g., Tag.A and Tag.B) and do a follow-up POST with tableTags: [Tag.C], only Tag.C will exist on all of the tables specified; tags Tag.A and Tag.B will be removed from all the data sources. Note: If you are frequently using the v2 API to update data tags, consider using the custom REST catalog integration instead.

Through this endpoint, you can create or update all data sources for a given schema or database.

POST /api/v2/data

Query parameters

Parameter	Description
dryRun	boolean If true, no updates will actually be made. Default: false
wait	number The number of seconds to wait for data sources to be created before returning. Anything less than 0 will wait indefinitely. Default: 0

Payload

Attribute	Description
connectionKey	string A key/name to uniquely identify this collection of data sources.
connection	object Connection information.
nameTemplate (optional)	object Supply a template to override naming conventions. Immuta will use the system default if not supplied.
options (optional)	object Override options for these sources. If not provided, system defaults will all be used.
owners (optional)	object Specify owners for all data sources created. If an empty array is provided, all data owners (other than the calling user) will be removed from the data source. To allow for an external process (or the UI) to control data owners, if the element is completely missing from the payload, data owners will not be modified.
sources (optional)	object Configure which sources are created. If not provided, all sources from the given connection will be created.

Note: See Create Data Source Payload Attribute Details for more details about these attributes.

Request payload examples

• Basic Data Source

• Databricks Data Source (Override Naming Convention)

• Impala Data Source (with userFile)

• Basic Postgres Data Source

• Snowflake Data Source (Specifies Sources)

Create a policy

POST /api/v2/policy

Query parameters

Parameter	Description
dryRun	boolean If true, no updates will actually be made. Default: false
reCertify	boolean If true (and if the certification has changed), someone will need to re-certify this policy on all impacted data sources. Default: false

Payload

Attribute	Description
policyKey	string A key/name to uniquely identify this policy.
name	string The name of the policy.
type	subscription or data The type of policy.
actions	object The actual rules for this policy (see examples).
ownerRestrictions (optional)	object[] Object identifying the entities to which this global policy should be restricted.
circumstances (optional)	object When this policy should get applied
circumstanceOperator (optional)	all or any Specify whether "all" of the circumstances must be met for the policy to be applied, or just "any" of them.
staged (optional)	boolean Whether or not this global policy is in a staged. status. Default: false
certification (optional)	object Certification information for the global policy.

Note: See Policy Request Payload Examples for payload details.

Request payload examples**

• Subscription Policies

• Data Policies:

  • Data Owner Restrictions

  • Masking Policies

  • Minimize Data Created Between

  • Purpose Restrictions

  • Row-level Policies

• Multiple Policies

Create a project

POST /api/v2/project

Query parameters

Parameter	Description
dryRun	boolean If true, no updates will actually be made. Default: false
deleteDataSourcesOnWorkspaceDelete	boolean If true, will delete all data and the data sources associated with a project workspace when the workspace is deleted. Default: false

Payload

Attribute	Description
projectKey	string A key/name to uniquely identify this project.
name	string The name of the project.
description (optional)	string A short description for the project.
documentation (optional)	object Markdown-supported documentation for this project.
allowedMaskedJoins (optional)	boolean If true, will allow joining on masked columns between data sources in this project. Only certain policies allow masked join. Default: false
purposes (optional)	string[] The list of purposes to add to this project.
datasources (optional)	string[] The list of data sources to add to this project.
subscriptionPolicy (optional)	object The policy for which users can subscribe to this project. Default: manual subscription policy
workspace (optional)	object If this is a workspace project, this is the workspace configuration. The project will automatically be equalized.
equalization (optional)	boolean If true, will normalize all users to the same entitlements so that everyone sees the same data. Default: false
tags (optional)	string[] Tags to add to the project.

Note: See Project Request Payload Examples for payload details.

Request payload examples

• Basic Project

• Project: Anyone Can Subscribe

• Project: Anyone Who is Approved

• Project: Users with Specific Groups or Attributes

• Project with Native Databricks Workspace

• Project with Snowflake Workspace

Create a purpose

POST /api/v2/purpose

Query parameters

Parameter	Description
dryRun	boolean If true, no updates will actually be made. Default: false
reAcknowledgeRequired	boolean If true, will require all users of any projects using this purpose to re-acknowledge any updated acknowledgement statements. Default: false

Payload

Attribute	Description
name	string The name of the purpose.
description (optional)	string A short description for the purpose.
acknowledgement (optional)	string The acknowledgement that users must agree to when joining a project with this purpose. If not provided, the system default will be used.
kAnonNoiseReduction (optional)	string The level of reduction allowed when doing policy adjustments on data sources in projects with this purpose.

Note: See Purposes Request Payload Examples for payload details.

Request payload examples

• Basic Purpose

• Advanced Purpose

• Sub-Purpose

Best practices

• Register all tables in a schema by enabling schema monitoring. Schema monitoring will negate the need to re-call the /data endpoint when you have new tables because schema monitoring will automatically recognize and register them.

• To frequently update data tags on a data source, use the custom REST catalog integration instead of the/data endpoint.

• Use the Data engineering with limited policy downtime guide. Rather than relying on re-calling the /data endpoint after a dbt run to update your data sources, follow the dbt and transform workflow and use schema monitoring to recognize changes to your data sources and reapply policies.