Source Controlling Data Products

You may want to maintain your data product definitions in source control and then push versions of those definitions to the Immuta Marketplace.

For example, consider the following data product definition which would be stored in a JSON file type in source control. It is also possible to store an array of data products in a single JSON file and pass that as your payload as well.

{
    "id": "4c8f6d82-e4c6-4478-92eb-d9342500f006",
    "name": "API Example",
    "description": "Data product created via the API",
    "metadata": {
        "subjectMatterExpert": {
            "id": "99aeadb5-352e-4872-9983-e628d399c36e"
        }
    },
    "domains": ["2ad33803-0a74-4ec6-8a1f-77693fb5f5fb"],
    "dataSources": [
        { "sourceId": "1" },
        { "sourceId": "6" },
        { "sourceId": "2" }
    ],
    "approvalPolicyId": "9c16db23-eecd-4f58-a72b-151ebea3b87e"
}

Notice the id key: it is possible to provide your own id on create as long as it meets standard UUID format. This id is how Immuta knows which data product you are editing if you send a new version of the data product definition to Immuta. The other objects referenced through UUIDs, such as the approvalPolicyId, can also be source controlled in the same manner, if desired.

The Immuta Marketplace is private preview and cannot guarantee backwards compatibility of the API until GA. In fact, it is highly likely the approvalPolicy name and definition will change soon.

It's important to understand that there are different API endpoints for create vs update of data products, but the payload is the same.

It is also possible to create a Terraform provider from the Immuta OpenAPI specification.