@celigo/api-specs 0.2.144 → 0.2.146

package/dist/export.yml

@@ -15728,6 +15728,11 @@ components:
         `transform` and output `filter` still run on top of them, so downstream steps — and a
         lookup's results mapping — see the transformed, filtered records, not the shape stored here.
 
+        In a flow test run of an HTTP export with a saved mock (live probe, 2026-10-21), the export
+        still listed `request` and `response` stages: `request` held the request the export composes,
+        and `response` held the mock under the source's URL, as did the test run's request log, which
+        recorded it as a 200. Read those stages as the substituted mock, not as a live call.
+
         `POST /v1/exports/preview` reads the `mockOutput` in its request body, not the saved one. For
         an export the preview supports (an HTTP export, for example), a body that carries it (as an
         export read back with GET does) returns that snapshot as a lone `parse` stage without calling

package/dist/flow.yml

@@ -2859,16 +2859,20 @@ paths:
       summary: Search jobs within a flow by trace key
       description: |-
         Searches for flow-run jobs that contain records matching a trace key prefix. Returns up to 1000
-        matching job objects — there is no pagination beyond that limit.
+        matching job objects — there is no pagination beyond that limit. A run matches when it carried
+        a matching record at all, whether the record succeeded, failed or was ignored there (live probe,
+        2026-10-21). Very short prefixes can match nothing — in that probe a two-character prefix of a
+        nine-character key found no run while three characters did — so send the record's whole trace
+        key.
 
-        The `traceKeyPrefix` query parameter is required; the server returns `400` when it is missing.
+        The `traceKeyPrefix` query parameter is required; the server returns `400` ("traceKeyPrefix is
+        required.") when it is missing.
 
-        Known behavior: the `status` filter is accepted but silently ignored — the response always includes
-        jobs of all statuses regardless of the filter value.
+        `status` filters the runs: in the same probe `status=failed` left out a `completed` run that
+        `status=completed` returned, and a value that is not a job status was ignored.
 
         Narrow the window with `createdAt_gte` / `createdAt_lte` when there are many runs for the
-        flow. Because `status` is silently ignored, filter client-side if you need only completed or
-        errored jobs.
+        flow.
       parameters:
         - name: _id
           in: path
@@ -2881,15 +2885,19 @@ paths:
         - name: traceKeyPrefix
           in: query
           required: true
-          description: Trace key prefix to search for. The server matches job records whose `traceKey` begins with this value.
+          description: |-
+            Trace key prefix to search for. The server matches job records whose `traceKey` begins with
+            this value, but very short prefixes can match nothing: in a live probe (2026-10-21) a
+            two-character prefix of a nine-character key found no run while three characters did. Send
+            the record's whole trace key.
           schema:
             type: string
         - name: status
           in: query
           required: false
           description: |-
-            Job status filter. **Note:** this parameter is currently accepted but silently ignored — all
-            statuses are always returned.
+            Job status filter: only runs with this status are returned. A value that is not a job
+            status is ignored (live probe, 2026-10-21).
           schema:
             type: string
         - name: createdAt_gte
@@ -2951,7 +2959,7 @@ paths:
                   value:
                     errors:
                       - code: invalid_request
-                        message: traceKeyPrefix query parameter is required.
+                        message: traceKeyPrefix is required.
         '401':
           $ref: '#/components/responses/401-unauthorized'
         '404':
@@ -3007,7 +3015,7 @@ paths:
             x-enumDescriptions:
               success: The record was processed successfully at this step.
               error: The record encountered an error during processing.
-              ignore: The record was skipped by a filter or routing rule.
+              ignore: The record was skipped at this step, by a filter, a router branch, or an import's ignore-existing or ignore-missing rule.
         - name: _expOrImpId
           in: query
           required: false
@@ -7842,11 +7850,11 @@ components:
           enum:
             - success
             - error
-            - ignored
+            - ignore
           x-enumDescriptions:
             success: The record was processed successfully at this step.
             error: The record encountered an error during processing.
-            ignored: The record was skipped by a filter or routing rule.
+            ignore: The record was skipped at this step, by a filter, a router branch, or an import's ignore-existing or ignore-missing rule.
         timeTaken:
           type: integer
           description: Milliseconds spent processing this record at this step.
@@ -8114,7 +8122,7 @@ components:
           x-enumDescriptions:
             success: The record was processed successfully at this step.
             error: The record encountered an error during processing.
-            ignore: The record was skipped by a filter or routing rule.
+            ignore: The record was skipped at this step, by a filter, a router branch, or an import's ignore-existing or ignore-missing rule.
         timeTaken:
           type: integer
           description: Milliseconds spent processing this record at this step.

package/dist/integration.yml

@@ -4280,7 +4280,9 @@ components:
             When true, the integration is a container for Celigo Sync resources — set it on
             `POST /v1/integrations` before creating syncs in it (`POST /v1/syncs` into an
             integration without it fails with `422 integration_not_for_sync`). Fixed at creation:
-            `PUT /v1/integrations/{_id}` ignores the field in both directions.
+            `PUT /v1/integrations/{_id}` ignores the field in both directions. Keep flows out of
+            it: a flow create isn't refused there. While the integration holds a sync, deleting
+            it fails with 422 "sync <id> must be deleted before you can delete integration <id>".
         aliases:
           type: array
           description: Named aliases that map to specific resources within the integration.

package/dist/job.yml

@@ -71,10 +71,13 @@ paths:
         forward, take the `createdAt` of the last record, subtract 1 ms, and
         pass it as `createdAt_lte`.
 
-        Active jobs (`queued` or `running`) are pinned to the top of the first
-        page even when they fall outside the date filters; `canceling` jobs are
-        not pinned. Account for this when paging — the first page can contain
-        records older filters would otherwise exclude.
+        In a live probe (2026-10-21) the date filters applied to a `running`
+        flow job too: created outside `createdAt_gte` / `createdAt_lte`, it was
+        left out of every date-filtered list, whether the query was scoped by
+        flow and integration, by integration, or not at all. `queued` and
+        `canceling` jobs were not tested; if `queued` jobs are pinned to the
+        first page, that page can hold rows the date filters would otherwise
+        exclude, so tolerate out-of-range rows when paging.
       parameters:
         - name: _integrationId
           in: query

package/dist/sync.yml

@@ -153,7 +153,9 @@ paths:
         Creates a sync inside an integration. Only `_integrationId` and
         `source._connectionId` are required — new syncs start as disabled drafts, so the
         destination, datasets, and schedule can be configured with later requests. Creating
-        a sync also registers its connections for the platform's replication runtime.
+        a sync also registers its connections for the platform's replication runtime: each
+        connection gets `microServices.workerGroup: "DIWorker"` and joins the integration's
+        `_registeredConnectionIds`.
       operationId: createSync
       tags:
         - Syncs
@@ -215,7 +217,8 @@ paths:
                       _connectionId: 6a2a95909e994395f3c2a4e6
                     destination: {}
                     driftPolicy:
-                      dataset: {}
+                      dataset:
+                        added: ignore
                       element: {}
         '400':
           description: |-
@@ -328,12 +331,14 @@ paths:
       summary: Update a sync
       description: |-
         Replaces a sync's configuration. Send the complete desired state: omitted optional
-        fields (`schedule`, `timezone`, destination details, `driftPolicy`) are cleared, not
-        preserved. `_integrationId` cannot be sent — the integration is fixed at creation.
+        fields (`schedule`, `timezone`, destination details, the `driftPolicy.element`
+        settings) are cleared, not preserved. `_integrationId` cannot be sent — the integration
+        is fixed at creation.
 
-        Set `disabled: false` to enable the sync once its source, destination, datasets, and
+        Set `disabled: false` to enable the sync once its source, a complete destination, and
         `historicDateTime` are configured; enabling an incomplete sync fails with
-        `422 sync_not_enabled`.
+        `422 sync_not_enabled`. Always send `disabled`: a PUT that omits it enables a sync
+        whose source, destination and `historicDateTime` are set.
       operationId: updateSync
       tags:
         - Syncs
@@ -356,9 +361,10 @@ paths:
               $ref: '#/components/schemas/Request'
             examples:
               configure:
-                summary: Name the sync and set its destination
+                summary: Name the sync and set its destination, keeping it disabled
                 value:
                   name: Salesforce Demo Sync
+                  disabled: true
                   schedule: '? 0 */6 * * *'
                   timezone: America/New_York
                   historicDateTime: '2022-07-04T18:30:00.000Z'
@@ -443,13 +449,19 @@ paths:
             sync configuration (`invalid_destination_sync_config`), two enabled
             datasets resolve to the same destination table
             (`conflicting_table_name`), a field exceeds its size limit
-            (`size_limit_exceeded`), or the drift policy is inconsistent
-            (`drift_policy_invalid_setup`).
+            (`size_limit_exceeded`), the drift policy is inconsistent
+            (`drift_policy_invalid_setup`), or the destination's application differs from
+            the integration's other syncs or from the sync's saved destination.
           content:
             application/json:
               schema:
                 $ref: '#/components/schemas/Error'
               examples:
+                mixed_destination_types:
+                  summary: Another destination application in the same integration
+                  value:
+                    errors:
+                      - message: The destination type for all the syncs under an integration must be same.
                 not_ready_to_enable:
                   summary: Enabling an incomplete sync
                   value:
@@ -464,6 +476,8 @@ paths:
         Deletes a sync and tears down its replication resources, including its datasets.
         The sync must be disabled first — deleting an enabled sync fails with
         `400 sync_delete_not_allowed`. Syncs are not recoverable through the recycle bin.
+        The sync's job records stay until their `purgeAt`, and while they exist the deleted
+        integration that held the sync can't be purged from the recycle bin.
       operationId: deleteSync
       tags:
         - Syncs
@@ -710,9 +724,11 @@ paths:
       description: |-
         Creates and updates a sync's datasets in one batch. Each array item either creates
         a dataset (identified by `externalId`) or updates one (identified by `_id`); a
-        single request can mix both. Updates fully replace each dataset's writable fields.
-        The response body is empty — read back the saved datasets with
-        `GET /v1/syncs/{_syncId}/datasets`.
+        single request can mix both. An update replaces the dataset's `name`, `tableName` and
+        `exportProperties` with what the item carries, so send each item whole. One failing
+        item rejects the whole batch, valid items included, and datasets the batch doesn't
+        name are left unchanged. The response body is empty — read back the saved datasets
+        with `GET /v1/syncs/{_syncId}/datasets`.
       operationId: upsertDatasetsForSync
       tags:
         - Syncs
@@ -761,12 +777,14 @@ paths:
                     exportProperties:
                       type: delta
               update:
-                summary: Switch an existing dataset to append mode
+                summary: Switch an existing dataset to append mode, sending the whole item
                 value:
                   - _id: 6a559b547885d8f93921c2ba
                     name: Account
                     enable: true
                     ingestionMode: append
+                    exportProperties:
+                      type: delta
                     dataElements:
                       - name: Id
                         enable: true
@@ -801,7 +819,8 @@ paths:
           description: |-
             Validation failed. An enabled dataset is missing `ingestionMode`
             (`ingestion_mode_required_for_enabled_datasets`), a `merge` dataset has no
-            primary key, a `tableName` is already taken, two source columns sanitize to
+            primary key, a `tableName` is already taken (or, for an enabled dataset, matches
+            another dataset's table name in another letter case), two source columns sanitize to
             the same destination column name (`duplicate_sanitized_column_names` — rename
             or disable the conflicting source columns), or a data-element combination is
             invalid (e.g. `transformMode` without children, or `isPrimaryKey` with `mask`).
@@ -1043,7 +1062,7 @@ paths:
                   value:
                     errors:
                       - code: sync_job_already_queued
-                        message: A sync job is already queued for this sync.
+                        message: Another instance for this sync is already queued or running. Please try again later.
         '422':
           description: |-
             The sync is disabled and cannot be run.
@@ -1058,7 +1077,7 @@ paths:
                   value:
                     errors:
                       - code: invalid_sync
-                        message: The sync is disabled.
+                        message: Sync disabled. Please enable your sync and try again.
   /v1/syncs/{_syncId}/syncJobs:
     get:
       x-internal: false
@@ -1286,7 +1305,7 @@ paths:
                   value:
                     errors:
                       - code: sync_jobs_not_found
-                        message: No cancellable sync jobs found.
+                        message: 'Sync jobs not found for syncId: <syncId>'
         '409':
           description: |-
             Cancellation is already in progress for the remaining jobs.
@@ -1740,7 +1759,7 @@ paths:
                   value:
                     errors:
                       - code: sync_job_invalid_integration_id
-                        message: The integration is not sync-enabled.
+                        message: The integration <integrationId> is not allowed to have syncs
                 missing:
                   summary: Integration does not exist
                   value:
@@ -2856,7 +2875,10 @@ paths:
         Returns the full column/field catalog for one table/object on a connection, as read
         from the source application. Use it to build the `dataElements` selection before
         saving a dataset via `PUT /v1/syncs/{_syncId}/datasets` — each element's `name` here
-        is the `name` to reference there.
+        is the `name` to reference there. Read an export's record structure (`isExport=true`)
+        or an HTTP-connector object's columns through
+        `GET /v1/di/metadata/sync/{_syncId}/connections/{_connectionId}/datasets/{datasetName}/details`
+        once a draft sync exists.
       operationId: getConnectionDatasetDetails
       tags:
         - Syncs
@@ -3149,6 +3171,11 @@ paths:
               schema:
                 $ref: '#/components/schemas/Error'
               examples:
+                export_or_connector_object:
+                  summary: An export or HTTP-connector object (read it through the sync-scoped route)
+                  value:
+                    errors:
+                      - message: 'A required parameter is missing: _datasetId'
                 unknown_dataset:
                   summary: Table does not exist in the source
                   value:
@@ -3763,7 +3790,8 @@ components:
         How the sync reacts when the source schema changes between runs (schema drift).
         `dataset` covers whole tables/objects appearing or disappearing; `element` covers
         individual columns/fields. Drift the policy automates is logged as `Schema Drift`
-        events, readable via `GET /v1/di/resource/syncs/{_syncId}/events`.
+        events, readable via `GET /v1/di/resource/syncs/{_syncId}/events`. A PUT that omits the
+        `element` settings clears them.
       properties:
         dataset:
           type: object
@@ -3777,7 +3805,9 @@ components:
               description: |-
                 Handling for tables/objects that appear in the source after the sync was
                 configured. Choose `ignore` to keep the replicated set fixed and add new
-                tables manually.
+                tables manually. A sync created through the API starts at `ignore`, and a PUT
+                that omits `driftPolicy` or sends an empty `dataset` object keeps the stored
+                value, so moving back from `automate` takes an explicit `ignore`.
               x-enumDescriptions:
                 automate: Automatically add newly discovered tables to the sync and start replicating them.
                 ignore: Leave newly discovered tables out of the sync until a user enables them.
@@ -3800,8 +3830,8 @@ components:
       type: object
       description: |-
         A sync continuously replicates data from a source application into a data warehouse.
-        New syncs start as disabled drafts; a sync can only be enabled once its source,
-        destination, and datasets are fully configured.
+        New syncs start as disabled drafts; a sync can be enabled once its source, a complete
+        destination, and `historicDateTime` are configured.
       required:
         - _id
         - _userId
@@ -3909,8 +3939,8 @@ components:
             destination yet. The destination application is the connection's own type
             (`rdbms.type` for warehouse connections), so `database` and `schema` are read in that
             application's terms — Google BigQuery treats them as the GCP project and the dataset.
-            Each source + destination host/database/schema combination must be unique across
-            syncs — reusing one fails with `422 duplicate_destination_host` — and all syncs in an
+            A `database` and `schema` pair can back only one sync, even across integrations — reusing one,
+            in any letter case, fails with `422 duplicate_destination_host` — and all syncs in an
             integration must target the same destination application type.
           properties:
             _connectionId:
@@ -3991,8 +4021,9 @@ components:
       description: |-
         Writable sync fields for `POST /v1/syncs` and `PUT /v1/syncs/{_id}`. Updates are full
         replacements: omitted optional fields (`schedule`, `timezone`, `destination` details,
-        `driftPolicy`) are cleared, not preserved, so send the complete desired configuration
-        on every PUT.
+        the `driftPolicy.element` settings) are cleared, not preserved, so send the complete
+        desired configuration on every PUT. A PUT that omits `disabled` returns the sync enabled
+        (`disabled: false`) when its source, destination and `historicDateTime` are set.
       required:
         - source
       x-celigo-ai-guidance:
@@ -4015,6 +4046,16 @@ components:
           integration created without it fails the sync create with 422 integration_not_for_sync
           ("An integration is suppose to have either flows or syncs but not both"), and PUT
           /v1/integrations/{_id} ignores the syncs field, so the only fix is a new integration.
+        - |-
+          Send disabled explicitly on every PUT. A PUT that omits it returns disabled: false once
+          the sync's source, destination and historicDateTime are complete; disabled: true in the
+          body keeps it disabled.
+        - |-
+          Creating a sync, and saving its destination, registers the connections with the
+          replication runtime: the platform sets microServices.workerGroup to "DIWorker" on each
+          connection (a system change in its audit log) and adds them to the integration's
+          _registeredConnectionIds. Deleting the syncs that used a connection cleared its worker
+          group when no other sync used it.
       properties:
         _integrationId:
           type: string
@@ -4044,11 +4085,12 @@ components:
             - Replicates core CRM objects into the analytics warehouse.
         disabled:
           type: boolean
-          default: true
           description: |-
-            When true, the sync neither runs on schedule nor accepts on-demand runs. Set to
-            false only once source, destination, datasets, and `historicDateTime` are all
-            configured; enabling an incomplete sync fails with `422 sync_not_enabled`.
+            When true, the sync neither runs on schedule nor accepts on-demand runs. A PUT that
+            omits it returns the sync enabled once its source, destination and `historicDateTime`
+            are set, so send it on every PUT. Set to false once the source, a complete
+            destination, and `historicDateTime` are configured; enabling an incomplete sync fails with
+            `422 sync_not_enabled`. Datasets aren't checked: a sync with none enables.
           examples:
             - false
         schedule:
@@ -4101,9 +4143,10 @@ components:
             enabled. The destination application is the connection's own type (`rdbms.type`
             for warehouse connections), so `database` and `schema` are read in that
             application's terms — Google BigQuery treats them as the GCP project and the
-            dataset. The source + destination host/database/schema combination must be unique
-            across syncs (`422 duplicate_destination_host`), and all syncs in an integration
-            must target the same destination application type.
+            dataset. A `database` and `schema` pair, in any letter case, can back only one sync,
+            even across integrations (`422 duplicate_destination_host`, "Duplicate destination host found"). All syncs in
+            an integration must target the same destination application type, and a sync's
+            destination type can't change once saved.
           x-celigo-ai-guidance:
             - |-
               Send the block complete or not at all. A partial block is rejected in the destination's
@@ -4115,10 +4158,26 @@ components:
               `002003` "Database 'UNDEFINED' does not exist" error.
             - |-
               Saving a complete destination connects to the warehouse to create the schema
-              (dataset) when it is missing. An unreachable host or unusable credentials fail the
-              save with the connection's error — 422 `invalid_host` for SQL Server,
-              `big_query_unexpected_error` for BigQuery — and no sync document is created or
-              updated; fix the connection rather than changing database or schema names.
+              (dataset) when it is missing. When the host resolves but the connection fails, or
+              the credentials are unusable, the save fails with the connection's error — 422
+              `invalid_host` for SQL Server, `big_query_unexpected_error` for BigQuery — and no
+              sync document is created or updated; fix the connection rather than changing
+              database or schema names.
+            - |-
+              A destination host that doesn't resolve can leave the save without a response for
+              more than 30 seconds, with nothing saved (seen on SQL Server and Snowflake
+              connections). Read the sync back before sending it again.
+            - |-
+              The duplicate_destination_host check compares the database and schema names
+              without regard to case. It refused a pair already used by another sync even when
+              the host, the destination type, the source connection and the integration all
+              differed, so give each sync a schema of its own.
+            - |-
+              A destination whose application differs from the other syncs' in the same
+              integration fails with 422 "The destination type for all the syncs under an
+              integration must be same.", and changing a saved destination to another application
+              fails with 422 "Destination connection type is not same as the previous destination
+              connection type". Another warehouse type needs a new sync in its own integration.
             - |-
               Microsoft SQL Server validates `database` and `schema` as identifiers (start with a
               letter or underscore; letters, digits, underscore or `$`; at most 128 characters) and
@@ -4417,7 +4476,9 @@ components:
         One dataset to create or update in a `PUT /v1/syncs/{_syncId}/datasets` batch.
         Send `externalId` (without `_id`) to create, or `_id` (without `externalId`) to
         update — providing both or neither fails with `400 dataset_externalId_id_required`.
-        Updates are full replacements of the writable fields.
+        An update replaces `name`, `tableName` and `exportProperties` with what the item
+        carries, clearing any it omits; an omitted `ingestionMode` or `dataElements` keeps its
+        saved value. Send each update item whole.
       x-celigo-ai-guidance:
         - |-
           Create items with externalId only; update items with _id only. Sending both on one
@@ -4431,6 +4492,16 @@ components:
         - |-
           To scaffold a dataset without replicating it yet, send name, externalId, enable: false
           and no dataElements — the platform then replicates all columns once enabled.
+        - |-
+          A partial update item such as {_id, enable: false} is accepted and clears the dataset's
+          name and tableName — on an export-backed dataset too, whose create requires tableName.
+          Build each update item from the dataset's read-back, minus externalId and the read-only
+          fields.
+        - |-
+          Selections are not checked against the source at save: an externalId the catalog
+          doesn't list, and dataElements names a catalog table doesn't have (even an enabled
+          merge key), save without an error. Take externalId values from the connection's
+          dataset catalog and column names from its details read.
       properties:
         _id:
           type: string
@@ -4483,7 +4554,9 @@ components:
             Destination table name override. Must be unique among the sync's datasets —
             duplicates within the batch or with existing datasets fail with `400
             duplicate_dataset_table_names` / `422 table_name_already_exists`. Required when
-            `isExport` is true.
+            `isExport` is true. The save-time check matches exact names only; a name that
+            differs only in case saves, and enabling one of the two then fails with 422
+            "Another dataset in this sync resolves to the same destination table".
           examples:
             - account
         isExport:
@@ -5016,9 +5089,13 @@ components:
         stage:
           type: string
           readOnly: true
-          description: Pipeline stage where the error occurred.
+          description: |-
+            Pipeline stage where the error occurred. `init` errors come from the checks a run
+            makes before it extracts — `di_ping_failure` when a connection's host can't be
+            reached — and carry no table.
           examples:
             - extraction
+            - init
         datasetName:
           type: string
           readOnly: true

package/dist/tool.yml

@@ -36798,6 +36798,11 @@ components:
         `transform` and output `filter` still run on top of them, so downstream steps — and a
         lookup's results mapping — see the transformed, filtered records, not the shape stored here.
 
+        In a flow test run of an HTTP export with a saved mock (live probe, 2026-10-21), the export
+        still listed `request` and `response` stages: `request` held the request the export composes,
+        and `response` held the mock under the source's URL, as did the test run's request log, which
+        recorded it as a 200. Read those stages as the substituted mock, not as a live call.
+
         `POST /v1/exports/preview` reads the `mockOutput` in its request body, not the saved one. For
         an export the preview supports (an HTTP export, for example), a body that carries it (as an
         export read back with GET does) returns that snapshot as a lone `parse` stage without calling

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@celigo/api-specs",
-  "version": "0.2.144",
+  "version": "0.2.146",
   "private": false,
   "description": "Public OpenAPI bundles (dist/) and the celigo-cli lint schema pack (schemas.json).",
   "keywords": [

package/schemas.json

@@ -1,7 +1,7 @@
 {
 	"provenance": {
 		"repo": "celigo/integrator-api-specs",
-		"iasCommit": "3543542b",
+		"iasCommit": "debaf90f",
 		"generatedAt": "2026-10-21"
 	},
 	"roots": {