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

2026.6.1.0 API Release Notes

Update: Document API

Enhanced Documents API to improve request validation clarity, make authorization requirements explicit, and provide more complete metadata in custom field object references.

• parent_folder_id is now a required field for document creation requests.
• Added explicit permission documentation for create, update, and delete operations:
• Create requires EDIT on parent_folder_id
• Update and Delete require EDIT on the document id
• Expanded custom_fields response:
  • Added field_name
  • Added suspended (for user object refs) and deleted (for non-user object refs)

Update: Data Sources API (OCF)

Added support for a deleted query parameter on GET /integration/v2/schema/that allows you to pass ?deleted=true for retrieving soft-deleted schemas.

This brings schema listing behavior in line with the data source endpoint, which already supports filtering by deletion status and improves API consistency and makes it easier for clients to audit or restore schema-related state.

Note: Default behavior is unchanged: deleted schemas are still excluded unless explicitly requested.

Update: Lineage API

Enhanced Lineage API for Lineage and Dataflow endpoints to clearly describe query filter behavior and stitched-response semantics.

• Stitching behavior when filtered nodes are skipped

• Depth handling via lineage-service.filters.asset_depth

• Response shape for stitched multi-chain lineage

• Parallel-chain merge behavior in returned path/dataflow segments

For GET /integration/v2/lineage/:

• excludeTemp (default: false)
• excludeGone (default: true)
• direction (default: both)

For GET /integration/v2/dataflow/:

• excludeTemp (default: false)
• excludeGone (default: true)

Note: If your integration expects soft-deleted (“gone”) nodes, update requests to include:

• excludeGone=false

Update: Native Data Quality API

The Native Data Quality monitor APIs now accept notification channels at the individual check and anomaly level (in addition to existing monitor-level channels).

• In the public monitor payload, channels can now be set on:
  • check rules
  • anomaly rules
• channels is optional and uses the same channel object shape (channel_id, channel_name, channel_type).

Behavior

• Check/anomaly-level channels are independent of monitor-level channels.
• Notifications are additive (both can fire).
• Existing monitors and clients continue to work unchanged if they do not send nested channels.

Backward compatibility

• Backward compatible
• No migration required for existing public API clients
• No action required unless clients want per-check/per-anomaly routing

Update: Per-Object Parameters API

Enhanced the Per-Object Parameters API to improve lifecycle observability by introducing two new timestamps that better represent job progression.

• ts_created: when the job record was created
• ts_queued: when the job was queued for execution

These are now available in API responses (including job serializers and related job representations).

Behavior changes

• Default job listing/order behavior now uses creation time (newest by ts_created).
• For backward compatibility, existing clients using ts_started for ordering are supported via aliasing to creation-time ordering behavior.

Previously, ts_started often doubled as a proxy for creation/queue timing, making lifecycle latency analysis less accurate. With explicit creation and queue timestamps, clients can now distinguish:

• record creation latency
• queue latency
• start latency

This enables more precise monitoring and reporting for job execution pipelines.

Update: User V2 API

Updated User V2 API to include the status field in user responses.

• Added status to the User v2 OpenAPI schema (userv2.yaml)
• status is documented as a read-only string enum with possible values:
  • active
  • suspended
  • pending
• The User response schema now explicitly includes this field (including list and detail responses)