October 2026

Build production integrations on a stable foundation: platform APIs are now generally available.

Find everything you need in the new API reference: learn by example on every operation and start coding immediately with ready-made snippets in eight languages. The OpenAPI specification is enriched as well, so the same descriptions and examples show up in your own tooling.

To start building, visit api.docs.ataccama.com.

For more complex integration scenarios, walkthroughs remain available in the documentation. See API Overview.

Run read-only SQL queries over your published reference data through the new public API endpoint POST /reference-data/v1/sql/execute.

Unlike the per-table filter endpoints, a single SELECT statement can read and join multiple tables on conditions you define — ideal for cross-table lookups and richer integrations. Results always reflect the published data at the time of the call.

For details, see the API reference documentation.

Run edge processing on an Azure Kubernetes Service (AKS) cluster you operate, installed with a Helm chart. The Kubernetes edge supports AKS only, and authenticates to your Azure resources with an app registration client secret. Processing results are written to your own Azure Blob Storage, optionally encrypted with a key in your Azure Key Vault. Metadata and aggregates are sent to Ataccama ONE, and stored results are sent when a user views them. For details, see Where your data lives.

The Kubernetes edge is the right fit when:

To decide whether it fits your use case, compare it with the other deployment options in Edge Processing, review Kubernetes Edge Limitations for what it doesn’t support, and see Shared Responsibility Model for what you’ll own.

To get started, check Kubernetes Edge Supported Platforms, prepare your Azure resources and network access, then install the Kubernetes edge with Helm.

Keep sensitive data inside your edge environment without giving up data quality monitoring. Edge processing connections now have a Compliance mode setting:

This replaces the former Allow Edge export option. Existing connections are migrated automatically: those with Allow Edge export enabled now use Allow exports; all other connections use Normal (DQ results visible). When you create a new edge connection, you select a compliance mode before saving.

Connections without an edge instance are not affected — they’re processed in Ataccama Cloud, as before.

For details, see Compliance mode.

See every published version of a record, who published each change, and when. Technical history is recorded automatically for every reference data table, with or without effective dates, and covers published data only.

In time travel on the published data, switch the view to Technical to:

For tables that existed before this release, technical history includes all their earlier published versions.

For details, see View Technical History.

Export exactly the records you need from a reference data table to a CSV file.

You can now:

For details, see Export Reference Data Tables.

See a catalog item’s data quality, freshness, anomalies, and metadata at a glance, then break the results down by rule, attribute, or term. All monitor settings are now in one place: select Configure monitor to open them.

Notable changes include:

For details, see DQ Monitors.

Check the quality of only the records you need, such as the previous day’s orders or the customers in a single country, instead of the whole catalog item. A DQ monitor can now be limited to a data slice, a set of conditions on the catalog item’s attributes. DQ evaluation, profiling, and anomaly detection then run only on the records that match.

You can:

When you add, change, or remove a slice on a monitor that already has results, you choose whether to keep those results, put the slice on a new monitor, or delete the previous results.

Data slices are available on catalog items from most SQL connections. For details, see Data Slices.

Keep copies of your source data inside the platform: the new Allow invalid sample downloads setting controls whether users can download invalid samples as a CSV file. It’s off by default for new organizations, and existing organizations keep their current behavior. For details, see Allow invalid sample downloads.

Pushdown exports of invalid records to Snowflake and Databricks now build record_id from the key attributes you select in the export settings, the same way as non-pushdown exports. Previously, pushdown exports ignored the key attributes and used the primary key declared on the source table, stored as a JSON object, for example {"customer_id":1}. If the table had no declared primary key, or the asset was an SQL query, record_id was empty. Values are written the way your data source converts them to text, so dates and timestamps can look different from non-pushdown exports.

If you process exported records with your own queries, check the following:

For details, see Key attributes.

Pushdown exports of invalid records to Snowflake and Databricks now include records that a rule marks as invalid through its fallback result. The fallback result applies when a record matches none of the rule’s conditions. Previously, these records were missing from the export, even though the DQ monitor counted them as invalid.

The record limit now counts records, as it does for non-pushdown exports. A record that fails several rules counts once toward the limit and is exported once for every rule it fails. Previously, each exported row counted toward the limit, so an export could hold fewer records than the limit allowed.

For details, see Record limit.

Data quality dashboards were rebuilt in the August 2026 release. Organizations that already used dashboards could keep the original report and decide when to switch, using the Overview report setting at Global settings > DQ settings > DQ Dashboards.

The transition period has now ended. All dashboards show the rebuilt report, and the setting has been removed.

For details, see Data Quality Dashboards.