See Finding Your Alation Version for help determining which version of Alation you're using.

2025.3.2 API Release Notes

New

Alation Data Quality API

Introducing Public Bulk APIs for Alation Data Quality, allowing developers to programmatically manage and integrate with Alation features at scale.

• Create one or more DQ Monitors: POST /integration/v1/native_data_quality/monitor
• Retrieve monitors by query params (e.g., ?monitor_ids=79): GET /integration/v1/native_data_quality/monitor
• Update one or more monitors (bulk update): PUT /integration/v1/native_data_quality/monitor
• Delete monitors (bulk delete): DELETE /integration/v1/native_data_quality/monitor
• Trigger a check run for a monitor (single or bulk trigger depending on implementation): POST /integration/v1/native_data_quality/check_run

Updated

Expanded Access to Custom Fields API for Viewers

The Custom Fields public API endpoints now allows non-admin users to read custom-field resources (list and retrieve) when those fields pass field-level view permissions. Server and Catalog Admins continue to see the full set.

Mutations (create, update, or delete bulk operations) remain gated by edit permissions and are not opened to arbitrary non-admin reads or writes.

• /integration/v2/custom_fields/:
  • GET (list): Non-admins can now call this endpoint. The response will include all built-in fields and custom fields for which the user has field-level view permission. Admins will continue to see the full set of fields.
    • Limitation: Rules that require object context (e.g., in_people_set, is_admin) cannot be evaluated for the list call and are ignored. If a field's only view rules are of these types, it will not be returned to a non-admin.
  • POST (bulk create): This still requires EDIT permission. Non-admins will receive an HTTP 403 error. Admin flow remains unchanged.
• /integration/v2/custom_fields/{id}/:
  • GET (retrieve): Non-admins can retrieve a single custom field if they have field-level view permission for that specific field. Admins can see any field.
    If a non-admin requests a field they are not permitted to view, the request will result in a 404 (not found) rather than a 403 (forbidden).
  • PUT, DELETE: These methods remain gated by EDIT permissions. Only users with edit rights (admins or explicitly permitted users) can modify or delete custom fields.
    Note: Integrations that previously relied on non-admin GET requests being forbidden should note a change: GET requests are now permitted, but they are subject to field-level rules. This may lead to the following observations:
  • Non-Admin GET List Behavior: A GET list request made by a non-admin will return fewer fields compared to one made by an admin.
  • Non-Admin Single Custom Field GET Behavior: If a non-admin attempts a GET request for a single custom field they lack viewing permissions for, the response will be a "not found" (404) error, rather than a permission-denied (403) error.
  • Object-Scoped Rule Protection: Fields that are exclusively protected by object-scoped rules (such as in_people_set) will be hidden from non-admins in list responses. This is because these rules cannot be evaluated during a list call.
  • It's important to note that mutations (POST/PUT/DELETE) remain secure. These operations will continue to return a 403 error unless the caller possesses EDIT permissions. (AL-205069)

Allow Updating Vault Configuration of Data Sources

You can now update the vault configuration (e.g. Keypair) of OCF Datasources using the Datasource configuration PATCH API endpoint (integration/v2/datasource/{datasource_id}/configuration/).

Use the GET method first to get the existing configuration settings. The supported parameter_type fields are:

• TEXT
• ENCRYPTED_TEXT
• ENCRYPTED_BINARY

You can configure parameters to use external vault storage by appending _vault to the parameter key. Vault configuration fields are:

• is_vault_param: Enables or disables the vault storage.
• vault_config_name: Specifies the vault configuration name.
• valut_key: Specifies the vault key path.

Examples:

• Regular update:
  {"Jdbcuri_conf": "jdbc:postgresql://host:5432/db", "Enableautolineage_conf": true}
• Enable vault storage:
  {"Keypair_conf_vault": {"is_vault_param": true, "vault_config_name": "prod_vault", "vault_key": "datasources/postgres/jdbc_uri"}}
• Enable vault storage with AWS ARN:
  {"Password_conf_vault": {"is_vault_param": true, "vault_config_name": "aws_sm:AWS_Configuration", "vault_key": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/db/password"}}

Note: To use this, set the feature flag alation.api.vault_config.enabled to true. (AL-198802)

Bug Fixes

• Fixed an issue where the Context API failed with a 500 Internal Server Error when encountering unresolvable object set references, such as deleted objects or those filtered by permissions. The API now correctly handles these references without triggering an error. (AL-205055)
• Fixed an issue where Virtual Datasource API uploads failed to work with schema names containing a .period. (AL-58298)
• Fixed an issue where the Lineage API (integration/v2/lineage/) endpoint experienced a performance degradation. (AL-207501)
• Fixed an issue where column deletion behavior was inconsistent, preventing columns deleted via the /integration/v1/column/ endpoint from being restored after metadata extraction (MDE). Columns, tables, and schemas can now be consistently deleted using the /integration/v2/asset/ endpoint. (AL-134333)