@celigo/api-specs 0.2.150 → 0.2.152

package/dist/tool.yml

@@ -8543,7 +8543,12 @@ components:
           type: boolean
           description: |
             When true, uses iClient-managed OAuth credentials (clientId/clientSecret)
-            instead of the values in this configuration.
+            instead of the values in this configuration. The iClient is the connection's
+            `_iClientId` — on an HTTP connection `http._iClientId`, beside `auth`, not inside it —
+            and it also supplies the grant type and the authorization and token endpoints, so a
+            create needs only `auth.type: "oauth"`, `auth.oauth.useIClientFields: true` and the
+            iClient id. The connection holds no tokens until a person completes the authorization
+            in a browser.
         oauth1:
           type: object
           description: |-
@@ -8672,7 +8677,7 @@ components:
       x-celigo-ai-guidance:
         - |-
           ## OAUTH 2.0 GRANT TYPES
-          - "authorizationcode" — Authorization Code flow (browser-based user consent).
+          - "authorizecode" — Authorization Code flow (browser-based user consent).
             Requires authURI, tokenURI, and user authorization via browser.
           - "clientcredentials" — Client Credentials flow (server-to-server, no user).
             Requires tokenURI, clientId, clientSecret.
@@ -9263,7 +9268,11 @@ components:
                   description: |
                     The API key or bearer token value (encrypted at rest); returned masked as `"******"`.
                     On update, the mask sent back keeps the stored token; a new value replaces it.
-                    Required unless automatic token refresh is configured.
+                    Required unless automatic token refresh is configured: a token block without a
+                    token must carry a `refreshMethod`, so a create or update that sends neither fails
+                    with 422 `Expected field: refreshMethod to be present.` To create a static-token
+                    connection before the real token is available, send a placeholder value and
+                    replace it later.
                   examples:
                     - my-api-token-EXAMPLE
                 location:
@@ -11469,7 +11478,11 @@ components:
           description: |
             The API key or bearer token value (encrypted at rest); returned masked as `"******"`.
             On update, the mask sent back keeps the stored token; a new value replaces it.
-            Required unless automatic token refresh is configured.
+            Required unless automatic token refresh is configured: a token block without a
+            token must carry a `refreshMethod`, so a create or update that sends neither fails
+            with 422 `Expected field: refreshMethod to be present.` To create a static-token
+            connection before the real token is available, send a placeholder value and
+            replace it later.
           examples:
             - my-api-token-EXAMPLE
         location:
@@ -22380,12 +22393,17 @@ components:
                   run at `default` regardless of what's set here.
             output:
               type: object
-              description: Output format configuration
+              description: |-
+                Output format configuration. A guardrail stores `format` but doesn't use it: the
+                request to the model always carries the guardrail's own `validation_result` JSON
+                schema (`flagged`, `reasoning`, `confidence`), and the result returns `flagged` and
+                `reasoning` whatever `format` holds.
               properties:
                 format:
                   type: object
                   description: |
-                    Controls the structure of the model's output.
+                    Stored output structure. The request to the model uses the guardrail's own
+                    verdict schema instead (see `output`).
                   properties:
                     type:
                       type: string
@@ -22394,10 +22412,10 @@ components:
                         - json_schema
                         - blob
                       x-enumDescriptions:
-                        text: Free-form text response from the model.
-                        json_schema: Structured JSON output conforming to a defined schema.
-                        blob: Binary data output for non-text content.
-                      description: Output format type.
+                        text: Stored format type; the model request still uses the guardrail's verdict schema.
+                        json_schema: A stored JSON schema (`jsonSchema`); the model request still uses the guardrail's verdict schema.
+                        blob: Stored format type; the model request still uses the guardrail's verdict schema.
+                      description: Output format type, as stored.
                     schemaMode:
                       type: string
                       enum:
@@ -22407,9 +22425,9 @@ components:
                         manual: The schema editor opens `jsonSchema` in the visual field-by-field view
                         json: The schema editor opens `jsonSchema` in the raw JSON view
                       description: |-
-                        Which view a schema editor opens `jsonSchema` in; the schema sent to the
-                        provider is the same either way. Stored and echoed on guardrails for parity
-                        with the AI-agent format block — the guardrail form does not set it today.
+                        Which view a schema editor opens `jsonSchema` in. Stored and echoed on
+                        guardrails for parity with the AI-agent format block — the guardrail form
+                        does not set it today, and neither view changes the model request.
                       x-celigo-ai-guidance:
                         - |-
                           Resend the stored value on every update — a full PUT that omits the field
@@ -22421,18 +22439,20 @@ components:
                       x-celigo-ui-override: Required by the AI agent form when output format type is json_schema. Encoded here to mirror the form so builders produce connectable configurations.
                     strict:
                       type: boolean
-                      description: When true, enforces strict schema validation on output.
+                      description: Stored strict-validation flag for `jsonSchema`. A guardrail's model request uses its own verdict schema, so this doesn't apply there.
                       x-celigo-ai-guidance:
-                        - Whether to enforce strict schema validation on output
+                        - Stored only on a guardrail; it doesn't change the guardrail's verdict.
                     jsonSchema:
                       type: object
                       description: |
-                        JSON Schema for structured output. Required when `format.type` is "json_schema".
+                        Stored JSON Schema. Required when `format.type` is "json_schema". A guardrail
+                        doesn't send it to the model; the request carries the `validation_result`
+                        verdict schema instead.
                       x-celigo-ui-override: Required by the AI agent form when output format type is json_schema. Encoded here to mirror the form so builders produce connectable configurations.
                       properties:
                         type:
                           type: string
-                          description: Root JSON Schema type of the structured output; use "object" for record-shaped results.
+                          description: Root type of the stored JSON Schema.
                           enum:
                             - object
                             - array
@@ -22450,15 +22470,15 @@ components:
                         properties:
                           type: object
                           additionalProperties: true
-                          description: JSON Schema definitions for each field the structured output may contain.
+                          description: Field definitions in the stored JSON Schema.
                         required:
                           type: array
-                          description: Property names the model must include in the structured output.
+                          description: Property names the stored JSON Schema marks as required.
                           items:
                             type: string
                         additionalproperties:
                           type: boolean
-                          description: When true, the structured output may include properties beyond those defined in `properties`.
+                          description: Whether the stored JSON Schema allows properties beyond those in `properties`.
                     schema:
                       type: object
                       readOnly: true
@@ -25877,36 +25897,40 @@ components:
     Delta:
       type: object
       description: |-
-        Configures incremental exports that retrieve only records created or modified since the last
-        successful run. Required when the export's type is "delta"; omit for other export types.
-        The platform-managed last-successful-run timestamp (exposed as {{lastExportDateTime}}) is the
-        lower bound, and after a failed run the next run reuses the last successful timestamp so
-        changed records are not missed. A first run is not a full export: with no `startDate`, its
-        {{lastExportDateTime}} is the run's own timestamp (the value {{currentExportDateTime}} also
-        holds), so it picks up no earlier changes. Set `startDate` to reach back further. On success,
-        when `POST /v1/flows/{_id}/run` sends `export.endDate`, the flow's checkpoint is left at that
-        value, so an end date in the past moves the next run's lower bound back.
+        Configures incremental exports that retrieve only records created or modified since the
+        flow's delta checkpoint; omit it for other export types. Adaptors that compare a record field
+        name it in `dateField`, while HTTP exports and SQL queries carry {{lastExportDateTime}} in the
+        request and save without a delta object. Each run's window runs from {{lastExportDateTime}}
+        (the checkpoint) to {{currentExportDateTime}} (the time the run started). A first run is not a
+        full export: with no `startDate`, its {{lastExportDateTime}} is the run's own timestamp, so it
+        picks up no earlier changes. The checkpoint moves to a run's window end only when the run
+        exports records, so a run that exports nothing leaves it where it was, and after a failed run
+        the next run reuses the last checkpoint. On success, when `POST /v1/flows/{_id}/run` sends
+        `export.endDate`, the flow's checkpoint is left at that value, so an end date in the past
+        moves the next run's lower bound back.
       x-celigo-ai-guidance:
         - |-
-          This object is REQUIRED when the export's type field is set to "delta" and
-          should not be included for other export types.
+          Omit this object for export types other than "delta". An HTTP export with type
+          "delta" saves without it, since the request carries {{lastExportDateTime}}, but
+          set ``startDate`` anyway: without it the first run's window is empty.
           Delta exports are designed for efficient synchronization by retrieving only
           records that have been created or modified since the last execution.
         - |-
           ## REQUIRED FIELDS
           - ``startDate`` -- the initial cutoff timestamp the platform uses on the
             first run (and as the floor for ``{{lastExportDateTime}}`` thereafter).
-            Adapter-specific validators (e.g. NetSuite's ``transformTwoDotZero``)
-            reject delta configs that omit ``startDate`` with
-            ``missing_delta_startDate``, so this is effectively required for every
-            delta export.
+            Without it, a new flow's first run renders ``{{lastExportDateTime}}`` as
+            the run's own time, so the first run exports nothing (verified on HTTP
+            and RDBMS delta exports). Adapter-specific validators (e.g. NetSuite's
+            ``transformTwoDotZero``) reject delta configs that omit ``startDate``
+            with ``missing_delta_startDate``, so set it on every delta export.
         - |-
           ## DEFAULT CUTOFF BEHAVIOR (NO USER-SUPPLIED CUTOFF)
           When the user prompt does not specify an explicit cutoff timestamp,
           default ``startDate`` to **today at midnight UTC** in ISO-8601 format
           (e.g. ``"2026-05-14T00:00:00.000Z"``).  This means the first run picks
           up records changed today; subsequent runs use the platform-managed
-          ``{{lastExportDateTime}}`` (the last successful run timestamp).
+          ``{{lastExportDateTime}}`` (the end of the last run that exported records).
 
           - First run: filters records changed since ``startDate``.
           - Subsequent runs: uses ``{{lastExportDateTime}}`` as the lower bound;
@@ -25919,18 +25943,28 @@ components:
               - For HTTP exports: Use {{lastExportDateTime}} variable in relativeURI or body
               - For specific application adapters: Use dateField to specify timestamp fields
 
-          2. The system automatically maintains the last successful run timestamp
+          2. The system automatically maintains the checkpoint
               - No need to store or manage timestamps in your own code
               - A first run without ``startDate`` fetches nothing older than the run itself
-              - Subsequent runs use this timestamp as the starting point
+              - A run that exports records moves the checkpoint to its window end
+                ({{currentExportDateTime}}), where the next run starts
+              - Use {{lastExportDateTime}} as the lower bound; {{currentExportDateTime}} as the
+                lower bound asks for records changed after the run started, so every run exports nothing
 
           3. Error handling and recovery:
               - If an export fails, the next run uses the last successful timestamp
               - Records created/modified during a failed run will be included in the next run
+              - A run that exports nothing leaves the checkpoint where it was, so after a stretch of
+                empty runs the next run that finds records reaches back to the last run that exported
+                any: once the cause is fixed, no backfill run is needed
+              - A run given its own window (export.startDate / export.endDate on
+                POST /v1/flows/{_id}/run) that exports records leaves the checkpoint at endDate,
+                even a past one, so the next run re-reads everything after it
               - The lagOffset field can be used to handle edge cases
         - |-
-          This object is REQUIRED when the export's type field is set to "delta" and
-          should not be included for other export types.
+          Omit this object for export types other than "delta". An HTTP export with type
+          "delta" saves without it, since the request carries {{lastExportDateTime}}, but
+          set ``startDate`` anyway: without it the first run's window is empty.
           Delta exports are designed for efficient synchronization by retrieving only
           records that have been created or modified since the last execution.
       properties:
@@ -25946,8 +25980,9 @@ components:
             If the flow's own downstream steps update the exported records, add export criteria
             that exclude already-processed records (or use a creation-time field for process-once
             flows) so each run doesn't re-export what the previous run wrote. Not supported on
-            HTTP exports: embed {{lastExportDateTime}} in the relativeURI or body instead;
-            including dateField there makes the configuration invalid. For Salesforce this
+            HTTP exports: embed {{lastExportDateTime}} in the relativeURI or body instead; an HTTP
+            export saved with dateField is refused with 422 "Unsupported dateField in
+            export.delta.dateField". For Salesforce this
             field is required and defaults to the standard timestamp fields (LastModifiedDate,
             CreatedDate, SystemModstamp, LastActivityDate, LastViewedDate, LastReferencedDate) plus
             any custom timestamp fields.
@@ -25986,7 +26021,8 @@ components:
               ###CRITICAL ADAPTOR-SPECIFIC INSTRUCTION:
               - The adaptor type is HTTP. For HTTP exports, the "dateField" property MUST NOT be included in the delta configuration.
               - HTTP exports use the {{lastExportDateTime}} variable directly in the relativeURI or body instead of dateField.
-              - DO NOT include "dateField" in your response. If you include it, the configuration will be invalid.
+              - DO NOT include "dateField" in your response. If you include it, the save is refused with
+                422 "Unsupported dateField in export.delta.dateField".
 
               Example HTTP query with implicit delta:
               ```
@@ -26046,10 +26082,10 @@ components:
         dateFormat:
           type: string
           description: |-
-            Moment.js format string applied to the cutoff timestamp, including {{lastExportDateTime}}
-            when used in HTTP requests. Leave unset unless the source system requires a non-ISO8601
-            format; ISO 8601 is used by default. Date-only formats truncate the time portion,
-            widening the filter window.
+            Moment.js format string applied to both delta variables, {{lastExportDateTime}} and
+            {{currentExportDateTime}}, in HTTP requests and SQL queries alike. Leave unset unless the
+            source system requires a non-ISO8601 format; by default both render as ISO 8601 UTC with
+            milliseconds. Date-only formats truncate the time portion, widening the filter window.
           x-celigo-ai-guidance:
             - Defines the date/time format expected by the source system's API.
             - |-
@@ -26060,7 +26096,8 @@ components:
               - OPTIONAL: Only needed when the source system doesn't support ISO8601
               - Default: ISO8601 format (YYYY-MM-DDTHH:mm:ss.sssZ)
               - Uses Moment.js formatting tokens
-              - Directly affects the format of {{lastExportDateTime}} when used in HTTP requests
+              - Formats both {{lastExportDateTime}} and {{currentExportDateTime}}, in HTTP requests and in
+                SQL queries (an RDBMS delta query receives the formatted value as a quoted literal)
             - |-
               ## IMPLEMENTATION PATTERNS
 
@@ -26144,13 +26181,15 @@ components:
           format: date-time
           description: |-
             Lower-bound cutoff for the first run. Omitting it doesn't export history: the first run
-            then starts at its own timestamp. Set it to the earliest change the first run should pick
-            up. Subsequent runs use the platform-managed last-successful-run timestamp.
+            then starts at its own timestamp, an empty window. Set it to the earliest change the first
+            run should pick up. Later runs start from the flow's checkpoint, the end of the last run
+            that exported records.
           x-celigo-ai-guidance:
             - |-
               Initial cutoff timestamp for the first export run, in ISO-8601 UTC format (e.g.
               ``"2026-05-14T00:00:00.000Z"``).
-              REQUIRED for every delta export -- adapter-specific validators reject delta
+              Set it on every delta export: without it the first run's window is empty (verified
+              on HTTP and RDBMS delta exports), and adapter-specific validators reject delta
               configs without it (e.g.
               NetSuite returns ``missing_delta_startDate`` from the ``transformTwoDotZero`` processor).
             - |-
@@ -26162,10 +26201,11 @@ components:
               flow is being authored.
             - |-
               ## SUBSEQUENT RUNS
-              After the first successful run, the platform tracks the actual
-              last-run timestamp and exposes it as ``{{lastExportDateTime}}``;
-              ``startDate`` becomes the floor used only when the platform
-              timestamp is absent (e.g. after a reset).
+              After the first run that exports records, the platform keeps the
+              flow's checkpoint at the end of the last run that exported records
+              and exposes it as ``{{lastExportDateTime}}``; runs that export
+              nothing leave it unchanged. ``startDate`` becomes the floor used
+              only when the platform timestamp is absent (e.g. after a reset).
             - |-
               ## EXAMPLES
               - ``"2026-05-14T00:00:00.000Z"`` -- today at midnight UTC.
@@ -26174,7 +26214,8 @@ components:
             - |-
               Initial cutoff timestamp for the first export run, in ISO-8601 UTC format (e.g.
               ``"2026-05-14T00:00:00.000Z"``).
-              REQUIRED for every delta export -- adapter-specific validators reject delta
+              Set it on every delta export: without it the first run's window is empty (verified
+              on HTTP and RDBMS delta exports), and adapter-specific validators reject delta
               configs without it (e.g.
               NetSuite returns ``missing_delta_startDate`` from the ``transformTwoDotZero`` processor).
           examples:
@@ -26315,7 +26356,7 @@ components:
             - exported_to_netsuite
     Webhook:
       type: object
-      description: Configuration for webhook listeners that receive data through incoming HTTP requests. Required when the export's `type` is `webhook`; omit for other export types. The platform generates a unique endpoint URL, validates each incoming request using the configured `verify` method, passes the payload to subsequent flow steps, and returns a configurable HTTP response to the caller.
+      description: Configuration for webhook listeners that receive data through incoming HTTP requests. Required when the export's `type` is `webhook`; omit for other export types. Senders POST to the export's listener URL, `https://api.integrator.io/v1/exports/{_id}/data` (or the same path on the account's regional API host); the platform validates each request using the configured `verify` method, passes the payload to subsequent flow steps, and returns a configurable HTTP response to the caller. A request is answered 204 by default when accepted, 401 when it fails verification, and 403 `unable_to_run_flows` while every flow the export feeds is disabled; a refused request is not queued, so the sender must resend it.
       x-celigo-ai-guidance:
         - Configuration object for real-time event listeners that receive data via incoming HTTP requests.
         - |-
@@ -26689,7 +26730,7 @@ components:
             - sha1
         encoding:
           type: string
-          description: Encoding of the HMAC signature value when `verify` is `hmac`. Must match the encoding the webhook sender uses — a mismatch causes requests to be rejected even when the signature is otherwise correct.
+          description: 'Encoding of the HMAC signature value when `verify` is `hmac`. Must match the encoding the webhook sender uses — a mismatch causes requests to be rejected with a 401 even when the signature is otherwise correct. With `provider: custom`, `hex` is compared as lowercase hex: an uppercase hex signature is rejected.'
           x-celigo-ai-guidance:
             - Specifies the encoding format used for the HMAC signature in webhook requests.
             - |-
@@ -26785,7 +26826,7 @@ components:
             - 9d1a5c6b3e7d9f2a1c5b8e3aEXAMPLE
         header:
           type: string
-          description: Name of the request header that carries the HMAC signature when `verify` is `hmac`. Must match the header name the webhook sender uses (header names are case-insensitive); requests without this header are rejected with a 401. Signature prefixes in the header value (such as `sha256=`) are handled automatically.
+          description: 'Name of the request header that carries the HMAC signature when `verify` is `hmac`. Must match the header name the webhook sender uses (header names are case-insensitive); requests without this header are rejected with a 401. With `provider: custom` the header value must be the bare digest in the configured `encoding`: a value with a `sha256=` prefix is rejected with a 401.'
           x-celigo-ai-guidance:
             - Specifies the HTTP header name that contains the signature for HMAC verification.
             - |-
@@ -26831,8 +26872,9 @@ components:
 
               - The system will look for this exact header name in incoming requests
               - If the header is not found, the request will be rejected with a 401 error
-              - Some platforms may include a prefix in the header value (e.g., "sha256=")
-                which is handled automatically by the system
+              - Some platforms include a prefix in the header value (e.g., "sha256="). With
+                provider "custom" it is not stripped: a prefixed signature is rejected with a 401,
+                so the sender must send the bare digest
 
               IMPORTANT: This must exactly match the header name used by the webhook sender.
               If you're unsure about the correct header name, consult the sender's documentation
@@ -27907,11 +27949,12 @@ components:
             - metadata
         skipDelete:
           type: boolean
+          default: false
           description: |-
             When true, source files remain on the file server after processing; when false (the
             default), files are deleted after successful processing. Files that fail processing are
             never deleted, regardless of this setting. Enable retention when files must be processed
-            by other flows or kept for compliance.
+            by other flows or systems, or kept for compliance.
           x-celigo-ai-guidance:
             - |-
               Controls whether source files are retained or deleted after successful processing.
@@ -28584,8 +28627,10 @@ components:
               type: string
               description: |-
                 Character sequence separating fields within each row; comma when omitted. Use "\t"
-                for tab-delimited files; European-locale exports often use semicolons. An incorrect
-                delimiter is the most common cause of parsing failures.
+                for tab-delimited files; European-locale exports often use semicolons. A wrong
+                delimiter doesn't fail the parse: with a header row, each row becomes one field named
+                after the whole header line (`{"order_id;sku;qty": "1001;TEE-M;2"}`), so the failure
+                shows up in later steps.
               x-celigo-ai-guidance:
                 - |-
                   Specifies the character sequence that separates individual fields (columns)
@@ -31045,6 +31090,8 @@ components:
             Controls how the export requests subsequent pages when the API returns multi-page responses. The `method` field determines which companion fields are required and how each next page is requested. For the page, skip, and token methods, reference the matching pagination variable (`{{export.http.paging.page}}`, `{{export.http.paging.skip}}`, or `{{export.http.paging.token}}`) in the relative URI or request body — misconfigured pagination is a common cause of incomplete data retrieval.
 
             When this export is the first lookup of a builder-mode API with `pagination.enabled` set, it is that API's volume driver: saving the export (even unchanged) invalidates the API's issued cursors, so a caller mid-walk gets an empty final page, and removing `paging` is accepted on save but makes every call to the API fail with `400 api_pagination_source_not_paged` until paging is restored or the API's flag is turned off.
+
+            When a next page's response is identical to the previous one, paging stops: the export records an open error with code `page_response_error` ("Identical response received from next page request. No more page requests will be made.") and the run completes with the pages already read, so later pages are never exported. A request that doesn't change between pages produces this, as observed with `method: page` and the pagination variable missing from the relative URI and body; reference the variable so each request asks for the next page.
           x-celigo-ai-guidance:
             - Configuration object for navigating through multi-page API responses.
             - |-
@@ -34015,19 +34062,25 @@ components:
           description: |-
             Directory on the same server where files are moved after successful export, giving you
             an independent backup; if omitted, files are simply deleted from the source directory
-            after successful export (Celigo also keeps its own copy of processed files for a set
-            period). Supports static paths or handlebars templates.
+            after successful export unless `file.skipDelete` is true (Celigo also keeps its own copy
+            of processed files for a set period). Supports static paths or handlebars templates.
           x-celigo-ai-guidance:
             - Optional directory where files are moved before deletion.
             - |-
               IMPORTANT:
-              Celigo automatically deletes files from the source directory after successful export.
+              Celigo automatically deletes files from the source directory after successful export,
+              unless `file.skipDelete` is true. Moving them to a backup directory also takes them out
+              of the source directory, so when another system still reads them there, set
+              `file.skipDelete: true` instead.
               The backup directory is for users who want to maintain their own independent
               backup of exported files.
               Celigo also maintains its own backup of processed files for a set period of time.
             - |-
               IMPORTANT:
-              Celigo automatically deletes files from the source directory after successful export.
+              Celigo automatically deletes files from the source directory after successful export,
+              unless `file.skipDelete` is true. Moving them to a backup directory also takes them out
+              of the source directory, so when another system still reads them there, set
+              `file.skipDelete: true` instead.
               The backup directory is for users who want to maintain their own independent
               backup of exported files.
               Celigo also maintains its own backup of processed files for a set period of time.
@@ -36499,19 +36552,26 @@ components:
           description: |-
             Bucket in the same region where files are moved after successful export, giving you an
             independent backup; if omitted, files are simply deleted from the source bucket after
-            successful export (Celigo also keeps its own copy of processed files for a set period).
-            The connection's AWS credentials must have s3:PutObject permission on this bucket.
+            successful export unless `file.skipDelete` is true (Celigo also keeps its own copy of
+            processed files for a set period). The connection's AWS credentials must have
+            s3:PutObject permission on this bucket.
           x-celigo-ai-guidance:
             - Optional destination bucket where files are moved before deletion.
             - |-
               IMPORTANT:
-              Celigo automatically deletes files from the source bucket after successful export.
+              Celigo automatically deletes files from the source bucket after successful export,
+              unless `file.skipDelete` is true. Moving them to a backup bucket also takes them out of
+              the source bucket, so when another system still reads them there, set
+              `file.skipDelete: true` instead.
               The backup bucket is for users who want to maintain their own independent backup
               of exported files.
               Celigo also maintains its own backup of processed files for a set period of time.
             - |-
               IMPORTANT:
-              Celigo automatically deletes files from the source bucket after successful export.
+              Celigo automatically deletes files from the source bucket after successful export,
+              unless `file.skipDelete` is true. Moving them to a backup bucket also takes them out of
+              the source bucket, so when another system still reads them there, set
+              `file.skipDelete: true` instead.
               The backup bucket is for users who want to maintain their own independent backup
               of exported files.
               Celigo also maintains its own backup of processed files for a set period of time.
@@ -36967,7 +37027,9 @@ components:
             `NetSuiteExport` and `NetSuiteHTTPExport` both need a `netsuite` connection).
             Server-required unless `type` is `webhook` or `simple` (those receive data instead of
             fetching it) or `adaptorType` is `TopicExport` (Event Streams listeners are delivered
-            by the platform itself and must omit it).
+            by the platform itself and must omit it). A `WebhookExport` saved without `type: webhook`
+            is refused with 422 "_connectionId is required unless type is [webhook|simple]"; a webhook
+            export that does carry a connection saves and updates normally.
           examples:
             - 60a2c4e6f321d800129a1a3c
         adaptorType:
@@ -37088,9 +37150,11 @@ components:
           description: |-
             Operational mode of the export. When omitted, the export retrieves all available records —
             the standard batch mode, which is also the right choice for parsing structured files
-            (CSV/XML/JSON) into records. Each mode requires its matching configuration object
-            (e.g. a `delta` object when `type` is `delta`); use `blob` only to transfer raw files
-            without parsing their contents.
+            (CSV/XML/JSON) into records. Most modes take their matching configuration object (e.g. a
+            `webhook` object when `type` is `webhook`); an HTTP or SQL `delta` export saves without a
+            `delta` object because its request carries `{{lastExportDateTime}}`, though
+            `delta.startDate` sets its first window. Use `blob` only to transfer raw files without
+            parsing their contents.
           x-celigo-ai-guidance:
             - |-
               ## HOW TO PICK THE TYPE VALUE

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@celigo/api-specs",
-  "version": "0.2.150",
+  "version": "0.2.152",
   "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": "4f24ed04",
+		"iasCommit": "6336cc85",
 		"generatedAt": "2026-10-21"
 	},
 	"roots": {