BatchChange retrieves multiple entity changes by their IDs in a single request.
 This is an optimized endpoint for fetching specific changes when you already know their IDs,
 rather than listing changes for an entity.

Get apichangesv1batch

SYNQ integration_id that identifies the Airflow instance

Airflow task_id that identifies the task within the DAG

Id that identifies the custom entity
 The Id should be unique within the custom entity Identifier.

Dataproduct id that identifies the Dataproduct

Dbt node_id that identifies one of dbt DAG nodes (model, test, etc)

SYNQ integration_id that identifies the dbt Core project

EntityChange represents a change detected in an entity within the system.
 It tracks modifications to entities like Git commits, SQL definitions, and database schemas.

Identifiers of entities directly affected by this change.

SYNQ paths of entities directly affected by this change.

Timestamp when the change was detected by SYNQ.

Identifier of the entity on which the change was detected when available.

SYNQ path representing entity on which the change was detected when available,

GitCommitChange represents a change detected in a Git repository.

Name of the branch associated with the commit, if any.

URL of the Git repository where the commit was made.

Statistics about changes made to each modified file.

URL to e.g. Github which opens the Commit

ChangeStats contains statistics about changes made to a single file.

Signature contains information about the Git user who made the changes.

Timestamp when the signature was created.

Contains an arbitrary serialized message along with a @type that describes the type of the serialized message.

Identifier is a unique reference to an entity in SYNQ system. Entity identifiers
 are designed to closely mimic identifiers used by data platforms and tools. To construct
 an identifier, you need to know the kind of the entity and the ids that you would normally
 use to identify it in the data platform or tool. For example, to identify a table in BigQuery,
 you would need to know the project, dataset, and table names.

Airflow task identifier within a given DAG

Custom identifier to be used with all custom created entities

Dbt node that identifies one of dbt DAG nodes (model, test, etc) in dbt Cloud project

Dbt node that identifies one of dbt DAG nodes (model, test, etc) in dbt Core project

SYNQ integration_id of the monitored identifier

SchemaChange represents a change detected in a database schema.

List of changes made to individual columns in the schema.

SchemaColumnChange represents a specific change to a column in the schema.

ColumnAdditionChangeType represents the addition of a new column to the schema.

Position where the column was added in the schema.

ColumnNativeTypeChangeType represents a change in a column's data type.

ColumnRemovalChangeType represents the removal of a column from the schema.

Original position of the column in the schema.

SqlDefinitionChange represents a change detected in a SQL definition.

Timestamp when the current SQL state became valid.

Timestamp when the previous SQL state was valid.

Diff showing the changes between previous and current SQL.

SYNQ path that identifies the SYNQ entity, needs to be one of supported paths

bearerAuth

BatchChangeResponse contains the requested changes mapped by their IDs.

The `Status` type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by [gRPC](https://github.com/grpc). Each `Status` message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the [API Design Guide](https://cloud.google.com/apis/design/errors).

SYNQ Documentation

How to set up and get the most out of SYNQ

Introduction

SYNQ’s alerting is built around the ownership model to make getting notified about relevant issues as seamless as possible

Alerts overview

Setting up alerts

Tagging owners

Routing alerts

Business Alerts

Monitors are a core concept of SYNQ and help you proactively detect issues through self-learning and powerful anomaly monitors

Monitors overview

Setting up monitors

Setting up deployment rules

Configuring monitor sensitivity

Monitor feedback

Muting monitors

Defining monitors in code

SQL Tests

Table stats monitor

Volume monitor

Freshness monitor

Custom SQL monitor

SYNQ Data Products enables you to deploy relevant monitors, track uptime, and manage ownership of your business-critical data assets

Data products overview

Creating a data product

BI Status Badge

Owners clarify ownership of data assets and active workflows that help owners stay informed about the health and status of their data

Ownership overview

Creating an owner

Domains

Incident management helps you manage the issue resolution from start to finish and avoid anything getting lost when the stakes are high.

Incidents overview

SYNQ analytics gives you a birds-eye view of the health of your data stack so you can systemically improve what matters most

Get Started

Alerts

Monitors

Monitors Types

Data Products

Ownership

Incidents

Analytics

Lineage

BI Integrations

Data Warehouse Integrations

Transactional databases

Code Integrations

dbt Integrations

SQLMesh Integrations

Orchestration Tool Integrations

Alerting Integrations

Catalogs

Admin

Security

Support

Developer API

Get apichangesv1batch

Authorizations

Query Parameters

Response