@celigo/api-specs 0.2.132 → 0.2.134

package/dist/ai-agent.yml

@@ -1113,7 +1113,6 @@ components:
                 - gpt-5-mini
                 - gpt-5-nano
                 - gpt-4.1-mini
-                - gpt-4o
               x-celigo-ui-override: Required by the AI agent configuration form. Encoded here to mirror the form so builders produce connectable configurations.
               x-celigo-ai-guidance:
                 - |-
@@ -5790,7 +5789,8 @@ components:
             - filter
           description: |-
             Filter applied to incoming records before they are sent to the LLM. Records that match
-            continue through the agent; records that don't are silently dropped.
+            continue through the agent; records that don't skip it, counted as ignored with no model
+            call, and continue to the next step.
           allOf:
             - $ref: '#/components/schemas/Filter'
         responseTransform:

package/dist/export.yml

@@ -360,8 +360,9 @@ paths:
       x-internal: false
       summary: Clone an export
       description: |
-        Creates a copy of an existing export.
-        Supports optionally remapping referenced connections (via connectionMap).
+        Creates a copy of an existing export, remapping its connection through `connectionMap`.
+        For an export that uses a connection, omitting the map or sending an empty one fails with
+        400 `invalid_connectionMap`; map the connection to itself to keep it.
       operationId: cloneExport
       tags:
         - Exports
@@ -500,7 +501,11 @@ paths:
               description: |-
                 Full export document (mirror of `POST /v1/exports` body shape),
                 optionally with `test.limit` to cap preview record count. Omit
-                `_id` when previewing a not-yet-saved export.
+                `_id` when previewing a not-yet-saved export. For an export this
+                endpoint previews (an HTTP export, for example), a `mockOutput` in
+                the body is returned as a lone `parse` stage instead of a live read,
+                so remove it from a document read back with GET to sample the
+                source.
               additionalProperties: true
             examples:
               http_preview:
@@ -528,9 +533,9 @@ paths:
         '400':
           description: |-
             The export type does not support preview. Virtual (unsaved) previews
-            are rejected for `simple` and other virtual export types — only
-            builder-style exports (e.g. HTTP, RDBMS) can be previewed via this
-            endpoint.
+            are rejected for `simple`, `webhook` and other virtual export types —
+            only builder-style exports (e.g. HTTP, RDBMS) can be previewed via
+            this endpoint.
           content:
             application/json:
               schema:
@@ -633,8 +638,9 @@ paths:
         validation (bad ID, missing auth).
 
         This endpoint executes the export against the live source system.
-        `POST /v1/exports/preview` also queries the live source (reads only,
-        no job) — prefer it when you only need to inspect fetched records.
+        `POST /v1/exports/preview` also queries the live source when its body
+        carries no `mockOutput` (reads only, no job) — prefer it when you only
+        need to inspect fetched records.
       parameters:
         - in: path
           name: _id
@@ -5485,7 +5491,7 @@ components:
             Selects which files are processed: files matching the filter criteria are exported,
             and non-matching files are skipped entirely before processing begins. Filterable
             fields come from each file's metadata — most providers expose filename, filesize,
-            and lastmodified (e.g. ["endswith", ["extract", "filename"], ".csv"]).
+            and lastmodified (e.g. ["endswith", ["string", ["extract", "filename"]], ".csv"]).
           allOf:
             - $ref: '#/components/schemas/Filter'
           x-celigo-ai-guidance:
@@ -5500,7 +5506,7 @@ components:
 
               1. **filename**: The name of the file (with extension)
                 - Example filter: Match files with specific extensions or naming patterns
-                - Usage: `["endswith", ["extract", "filename"], ".csv"]`
+                - Usage: `["endswith", ["string", ["extract", "filename"]], ".csv"]`
 
               2. **filesize**: The size of the file in bytes
                 - Example filter: Skip files that are too large or too small
@@ -5508,7 +5514,7 @@ components:
 
               3. **lastmodified**: The last modification timestamp of the file
                 - Example filter: Process only files created/modified within a specific date range
-                - Usage: `["greaterthan", ["extract", "lastmodified"], "2023-01-01T00:00:00Z"]`
+                - Usage: `["greaterthan", ["epochtime", ["extract", "lastmodified"]], 1672531200000]` (2023-01-01T00:00:00Z in epoch milliseconds)
         backupPath:
           type: string
           description: Path where backup copies of source files are stored before processing.
@@ -5769,38 +5775,10 @@ components:
         bearerToken:
           type: string
           description: |-
-            Bearer token used to authenticate inbound distributed export requests. Optional — most
-            distributed listeners (NetSuite, Salesforce real-time) use no token. Write-only and stored
-            encrypted; treat it as a sensitive credential.
-          x-celigo-ai-guidance:
-            - |-
-              ## FIELD BEHAVIOR
-
-              This token provides authentication for the distributed export:
-
-              - Required for secure access to distributed endpoints
-              - Must be a valid bearer token format
-              - Used in Authorization header as "Bearer {token}"
-              - Should be kept secure and rotated regularly
-            - |-
-              ## IMPLEMENTATION GUIDANCE
-
-              ### Token management
-
-              - Store tokens securely (encrypted at rest)
-              - Implement token rotation policies
-              - Monitor token expiration dates
-              - Use environment variables for token storage
-
-              ### Security considerations
-
-              - Never log bearer tokens in plain text
-              - Implement proper access controls
-              - Use HTTPS for all token transmissions
-              - Validate tokens on each request
-
-              IMPORTANT: Bearer tokens provide full access to the distributed export.
-              Treat them as sensitive credentials.
+            Bearer token that a system pushing data into this export sends as
+            `Authorization: Bearer <token>`. Optional — most distributed listeners (NetSuite,
+            Salesforce real-time) use no token. Write-only and stored encrypted; treat it as a
+            sensitive credential.
           format: password
           examples:
             - eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
@@ -6196,7 +6174,7 @@ components:
               (`http.paging.body` likewise from its paging fields). A body that is not parseable JSON at
               rest — Handlebars block helpers outside a string value — renders every field EMPTY in that
               form, so keep templated variables inside a JSON string value:
-              `"variables": "{\"after\": {{#if export.http.paging.token}}\"{{export.http.paging.token}}\"{{else}}null{{/if}}}"`.
+              `"variables": "{\"after\": {{#if export.http.paging.token}}\"{{export.http.paging.token}}\"{{else}}null{{/if}} }"`.
             - |-
               The GraphQL form has no relative URI field: the connection `baseURI` is expected to be the
               GraphQL endpoint (a saved `relativeURI` still applies but is not shown). Create GraphQL
@@ -15640,9 +15618,10 @@ components:
 
         In a flow test run, and for an upstream lookup during a page-processor preview
         (`previewPageProcessor`), integrator.io substitutes this mock output for the export's live
-        response instead of calling the source. It is not substituted anywhere else: a target lookup
-        in that preview runs its live query, `POST /v1/exports/preview` calls the source, and real
-        runs ignore it. This allows you to:
+        response instead of calling the source. A saved mock is not read anywhere else: a target
+        lookup in that preview runs its live query, invoking the export
+        (`POST /v1/exports/{_id}/invoke`) reads the source, and real runs ignore it. This allows you
+        to:
         - Test mappings with representative data
         - Configure downstream flow steps without waiting for real data
         - Simulate various data scenarios
@@ -15651,6 +15630,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.
 
+        `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
+        the source; remove `mockOutput` from the body to preview live records.
+
         **Limitations**
 
         - Maximum of 10 records
@@ -15668,8 +15652,8 @@ components:
           the stored shape walks paths that do not exist at runtime.
         - |-
           A saved mockOutput is read in exactly two places — a flow test run, and an upstream lookup
-          during a page-processor preview. A target lookup's preview, `POST /v1/exports/preview` and
-          every real run call the source and never read it.
+          during a page-processor preview. A target lookup's preview, `POST /v1/exports/{_id}/invoke`
+          and every real run call the source and never read it.
       properties:
         page_of_records:
           type: array
@@ -16181,9 +16165,9 @@ components:
           x-celigo-agent:
             - filter
           description: |-
-            Filter applied to records immediately after they are retrieved from the source.
-            Records that match continue through the flow; records that don't are silently dropped.
-            Filter expressions reference the exported record's own fields.
+            Filter applied to each record after the export's transform and before its preSavePage
+            hook. Records that match continue through the flow; records that don't are silently
+            dropped. Filter expressions reference the transformed record's fields.
           allOf:
             - $ref: '#/components/schemas/Filter'
           x-celigo-ai-guidance:
@@ -16193,13 +16177,13 @@ components:
 
               ## FILTER BEHAVIOR
 
-              When configured, the filter is applied immediately after records are retrieved from the source system:
+              When configured, the filter is applied to each record after the export's transform and before the preSavePage hook:
               - Records that match the filter criteria continue through the flow
               - Records that don't match are silently dropped
               - No partial record processing is performed
 
               ## AVAILABLE FILTER FIELDS
-              The fields available for filtering are the data fields from each record retrieved by the export.
+              The fields available for filtering are those of each record as the export's transform leaves it (the retrieved record when no transform is set).
         inputFilter:
           x-celigo-agent:
             - filter
@@ -16312,9 +16296,12 @@ components:
               x-celigo-agent:
                 - script
               description: |-
-                Hook that runs after each page of records is retrieved from the source but before it
-                is sent to downstream steps. Commonly used to flatten structures, drop unwanted
-                records, or add computed fields.
+                Hook that runs on each page of records after the export's transform and output
+                filter, before the page is sent to downstream steps; commonly used to flatten
+                structures, drop unwanted records, or add computed fields. It receives the page as
+                `options.data` (with `errors`, `pageIndex`, `configuration` and `settings`) and returns
+                `{data, errors, abort, newErrorsAndRetryData}`. An exception thrown here fails every
+                record on that page, each with its own retry data, and later pages still run.
               properties:
                 function:
                   type: string
@@ -17114,8 +17101,10 @@ components:
         connectionMap:
           type: object
           description: |
-            Optional mapping of original connection ids to replacement connection ids.
+            Mapping of original connection ids to replacement connection ids.
             Keys are source connection ids on the original resource; values are target connection ids.
+            For an export that uses a connection, omitting the map or sending an empty one fails
+            with 400 `invalid_connectionMap`; map the connection to itself to reuse it in the clone.
           additionalProperties:
             type: string
           example:
@@ -17155,6 +17144,7 @@ components:
             Final sampled records produced by the preview — the output of the last
             stage. Identical in practice to the last `stages[].data` entry, exposed
             here as a convenience for callers that only care about the end result.
+            Absent from the zero-record answers described under `stages`.
           items: {}
         dataURIs:
           type: array
@@ -17177,10 +17167,15 @@ components:
             runs through parsing only — the export's transform, output filter,
             and preSavePage hook are NOT applied here (they run in flow
             previews, test runs, and real runs). Observed stage names: `parse`
-            always; `request` and `raw` for HTTP exports; `group` when the
-            export groups records (grouped records are bare arrays of the
-            grouped rows). Each stage carries its `data[]` output and any
-            `errors[]` raised at that stage.
+            for a live read that returned records, and as the only stage when a
+            `mockOutput` in the request body answers; `request` and `raw` for HTTP
+            exports; `group` when the export groups records (grouped records are
+            bare arrays of the grouped rows). Each stage carries its `data[]`
+            output and any `errors[]` raised at that stage. A live read that
+            selects no records has been observed without a `parse` stage or
+            top-level `data` on two adaptors: an HTTP export returns only `request`
+            and `raw`, and a NetSuite RESTlet search returns an empty object. Treat
+            those as zero records, not as a failed preview.
           items:
             type: object
             description: One pipeline stage's diagnostic and output envelope.

package/dist/flow.yml

@@ -8249,6 +8249,7 @@ components:
             Final sampled records produced by the preview — the output of the last
             stage. Identical in practice to the last `stages[].data` entry, exposed
             here as a convenience for callers that only care about the end result.
+            Absent from the zero-record answers described under `stages`.
           items: {}
         dataURIs:
           type: array
@@ -8271,10 +8272,15 @@ components:
             runs through parsing only — the export's transform, output filter,
             and preSavePage hook are NOT applied here (they run in flow
             previews, test runs, and real runs). Observed stage names: `parse`
-            always; `request` and `raw` for HTTP exports; `group` when the
-            export groups records (grouped records are bare arrays of the
-            grouped rows). Each stage carries its `data[]` output and any
-            `errors[]` raised at that stage.
+            for a live read that returned records, and as the only stage when a
+            `mockOutput` in the request body answers; `request` and `raw` for HTTP
+            exports; `group` when the export groups records (grouped records are
+            bare arrays of the grouped rows). Each stage carries its `data[]`
+            output and any `errors[]` raised at that stage. A live read that
+            selects no records has been observed without a `parse` stage or
+            top-level `data` on two adaptors: an HTTP export returns only `request`
+            and `raw`, and a NetSuite RESTlet search returns an empty object. Treat
+            those as zero records, not as a failed preview.
           items:
             type: object
             description: One pipeline stage's diagnostic and output envelope.

package/dist/import.yml

@@ -372,8 +372,9 @@ paths:
       x-internal: false
       summary: Clone an import
       description: |
-        Creates a copy of an existing import.
-        Supports optionally remapping referenced connections (via connectionMap).
+        Creates a copy of an existing import, remapping its connection through `connectionMap`.
+        For an import that uses a connection, an empty map fails with 400 `invalid_connectionMap`;
+        map the connection to itself to keep it.
       operationId: cloneImport
       tags:
         - Imports
@@ -549,6 +550,10 @@ paths:
         composed, not delivered — an FTP import against an unreachable host
         still returns `{name, fileLocation}`.
 
+        The import runs with its own `settings` only: hooks receive
+        `options.settings` with an `import` key but no `integration` or `flow`
+        key, and no `_flowId` or `_integrationId`.
+
         The import must be saved; to run an import definition that is not saved
         (or a modified copy of one), use the virtual import
         `POST /v1/connections/{_id}/import`, which takes the import document in
@@ -1303,7 +1308,7 @@ components:
               ## EXAMPLES:
               - `{ "UserId": "12345", "Name": "John Doe", "Age": 30, "Preferences": { "Language": "en", "Notifications": true } }`
           examples:
-            - '{"id": "{{record.id}}", "name": "{{record.name}}", "total": {{record.total}}}'
+            - '{"id": "{{record.id}}", "name": "{{record.name}}", "total": {{record.total}} }'
         updateExpression:
           type: string
           x-celigo-ui-override: Required by the DynamoDB import form when method is updateItem (dynamodb.updateExpression required, visibleWhen method=updateItem).
@@ -1966,7 +1971,10 @@ components:
               the Import's mapping step runs first and shapes the source record,
               then this template renders against that mapped record.
               Reference the mapped record with the ``record`` root when wrapping it (e.g.
-              ``{"requestData": {{{jsonSerialize record}}}}``).
+              ``{"requestData": {{{jsonSerialize record}}} }``).
+              Keep a literal ``}`` apart from a closing ``}}`` or ``}}}`` (a space is enough): the save
+              accepts ``{{{jsonSerialize record}}}}``, but every record then fails with
+              ``handlebars_template_parse_error``.
               Avoid bare ``{{{jsonSerialize record}}}`` with no wrapper — leave the field undefined instead.
               Also avoid wrapping a single post-mapped scalar field in ``jsonSerialize`` (e.g.
               ``{{{jsonSerialize record.<scalar>}}}``) — that pattern is brittle.
@@ -2029,9 +2037,9 @@ components:
 
               Typical shapes:
               - Message-bus envelope:
-                ``{"MessageBody": {"class": "EntityUpdate", "payload": {{{jsonSerialize record}}}}}``
+                ``{"MessageBody": {"class": "EntityUpdate", "payload": {{{jsonSerialize record}}} }}``
               - Metadata wrap:
-                ``{"batchNumber": "{{timestamp dateTimeFormat CST}}", "interfaceType": "...", "requestData": {{{jsonSerialize record}}}}``
+                ``{"batchNumber": "{{timestamp dateTimeFormat CST}}", "interfaceType": "...", "requestData": {{{jsonSerialize record}}} }``
               - Named single-record array wrap (when destination wants ``[record]`` but each request sends one):
                 ``{"products": [{{{jsonSerialize record}}}]}``
 
@@ -2072,7 +2080,7 @@ components:
               current ``{{#each data}}`` item.
 
               Example shape:
-              ``{"header": {"sellerId": "{{connection.http.unencrypted.sellerId}}"}, "messages": [{{#each data}}{"sku": "{{sku}}", "qty": {{quantity}}}{{/each}}]}``
+              ``{"header": {"sellerId": "{{connection.http.unencrypted.sellerId}}"}, "messages": [{{#each data}}{"sku": "{{sku}}", "qty": {{quantity}} }{{/each}}]}``
             - |-
               ## Anti-pattern — DO NOT wrap a post-mapped scalar in jsonSerialize
 
@@ -2157,7 +2165,7 @@ components:
                 mix the two shapes in one body.
           examples:
             - - '{"name": "{{record.name}}", "email": "{{record.email}}"}'
-            - - '{"requestData": {{{jsonSerialize record}}}}'
+            - - '{"requestData": {{{jsonSerialize record}}} }'
             - - '{"values": [{{#each batch_of_records}}{{{jsonSerialize this.record}}}{{#unless @last}},{{/unless}}{{/each}}]}'
           x-celigo-agent:
             - handlebars
@@ -2647,9 +2655,7 @@ components:
 
             The referenced helper bundles the polling config plus a required status
             export (polled to check progress) and a result export (fetches the
-            final payload). An import configured with an async helper cannot carry
-            its own transform, output filter, or preSavePage hook — put that
-            processing in the result export instead.
+            final payload).
           examples:
             - 60a2c4e6f321d800129a1a3c
           x-celigo-agent:
@@ -2733,7 +2739,7 @@ components:
 
               - **Static** — only ``map`` + optional ``default``.  No HTTP
                 request issued.  Use for small controlled vocabularies.
-              - **Dynamic** — ``method`` + ``relativeURI`` (+ ``postBody``,
+              - **Dynamic** — ``method`` + ``relativeURI`` (+ ``body``,
                 ``headers``, ``extract``).  Issues a live HTTP request per
                 lookup.  Adds one HTTP request per record at runtime — factor
                 this into flow design for high-volume syncs.
@@ -2771,14 +2777,18 @@ components:
                   inject values from the incoming record — e.g.
                   ``/customers?email={{{email}}}`` or
                   ``/accounts/{{{accountId}}}``.
-              postBody:
+              body:
                 type: string
                 x-celigo-agent:
                   - handlebars
                 description: |
-                  Request body template for POST / PUT / PATCH lookup methods.
-                  Typically a JSON string with Handlebars placeholders —
-                  ``{"email":"{{{email}}}"}``. Ignored for GET / DELETE.
+                  Request body template for POST / PUT / PATCH lookup methods, typically
+                  a JSON string with Handlebars placeholders (``{"email":"{{{email}}}"}``);
+                  ignored for GET / DELETE. The record's fields sit at the top level:
+                  ``{{email}}`` renders the record's value, while ``{{record.email}}``
+                  renders empty.
+                x-celigo-ai-guidance:
+                  - 'Put the lookup''s request template here, not in ``postBody``: a ``postBody`` saves without an error but is not kept under ``http.lookups``, so the lookup goes out with no body and the run reports no error.'
               headers:
                 type: array
                 items:
@@ -4429,9 +4439,9 @@ components:
                                 line) to the rows that populate the
                                 subrecord.  Typically `$` when the
                                 subrecord data is carried on the same
-                                line item (the enclosing
-                                `lists[].jsonPath` has already selected
-                                the line).  Defaults to `$`.
+                                line item (iteration over the sublist
+                                has already selected the line).
+                                Defaults to `$`.
                             mapping:
                               type: object
                               description: |
@@ -5155,9 +5165,10 @@ components:
                   SQL `SELECT` statement that resolves the lookup value.
                   Typically returns a single row with a single column; use
                   `extract` to pick the column when the query returns multiple.
-                  Inject values from the incoming record with Handlebars — RDBMS
-                  queries use triple braces and the `record.` prefix:
-                  `SELECT id FROM users WHERE email = '{{{record.email}}}'`.
+                  Inject values from the incoming record with Handlebars and the
+                  `record.` prefix — double braces for strings, which the platform
+                  quotes and escapes, and triple braces for numbers:
+                  `SELECT id FROM users WHERE email = {{record.email}}`.
               extract:
                 type: string
                 description: |
@@ -5205,7 +5216,7 @@ components:
           description: |-
             SQL statements to execute; required when queryType is `["per_record"]`, `["per_page"]`, or `["first_page"]`, and typically contains a single statement.
             Each element is a complete SQL statement as a plain string — never a single bare string and never an array of objects (objects cause a Cast error).
-            Inject values from the incoming record with Handlebars using the `record.` prefix and triple braces, e.g. `'{{{record.name}}}'` for strings (single-quoted in the SQL) and `{{{record.quantity}}}` for numbers.
+            Inject values from the incoming record with Handlebars using the `record.` prefix: double braces for strings and dates (`{{record.name}}`; the platform quotes and escapes the value) and triple braces for numbers (`{{{record.quantity}}}`).
             Rendering is strict: a reference the render model cannot resolve (a bare `{{name}}` without prefix, or `record.*` when the arriving record is a grouped array) fails the step with `cannot_evaluate_handlebars` — it does not render an empty value.
             `record` and `rows` are aliases chosen by the arriving data's shape: an object record binds `record` (`rows` undefined); a grouped array-record (e.g. upstream `groupByFields`) binds `rows` (`record` undefined) — address grouped rows as `{{rows.0.field}}` or iterate `{{#each rows}}`.
             Double braces (`{{record.field}}`) output the value wrapped in single quotes with embedded quotes doubled, while triple braces output it raw; block helpers such as `{{#each}}` and `{{#if}}` use double braces as normal.
@@ -5219,7 +5230,7 @@ components:
               - CORRECT: ["INSERT INTO users (name, email) VALUES ({{record.name}}, {{record.email}})"]
               - WRONG: "INSERT INTO users ..."  (not an array)
               - WRONG: [{"query": "INSERT INTO users ..."}]  (objects are invalid — causes Cast error)
-              - WRONG: ["INSERT INTO users (name) VALUES ('{{name}}')"]  (missing record. prefix — rendering is strict, so the step fails with cannot_evaluate_handlebars)
+              - WRONG: ["INSERT INTO users (name) VALUES ({{name}})"]  (missing record. prefix — rendering is strict, so the step fails with cannot_evaluate_handlebars)
             - |-
               ## RDBMS HANDLEBARS SYNTAX
 
@@ -5253,7 +5264,7 @@ components:
                 | Numeric column value (INT, DECIMAL, ...) | `{{{record.field}}}`    |
                 | Stored procedure raw arg (already typed) | `{{{record.field}}}`    |
                 | Identifier (table/column name)           | `{{{record.field}}}`    |
-                | JSON literal (`PARSE_JSON`/JSONB)      | `{{{jsonSerialize record.subobject}}}` |
+                | JSON literal (`PARSE_JSON`/JSONB)      | `{{jsonSerialize record.subobject}}` (renders the JSON as a quoted string) |
 
               - **Block helpers** (`{{#each}}`, `{{#if}}`, `{{/each}}`,
                 `{{#unless}}`) use double braces as normal — they emit no value.
@@ -5272,7 +5283,7 @@ components:
               - Per-page batch (different Handlebars context — see `queryType: per_page` below): `["{{#each batch_of_records}}UPDATE staging SET done=1 WHERE id={{{this.record.id}}};{{/each}}"]`
           examples:
             - - INSERT INTO orders (id, total) VALUES ({{{record.id}}}, {{{record.total}}})
-            - - '{{#each batch_of_records}}UPDATE customers SET name=''{{{record.name}}}'' WHERE id={{{record.id}}};{{/each}}'
+            - - '{{#each batch_of_records}}UPDATE customers SET name={{record.name}} WHERE id={{{record.id}}};{{/each}}'
         queryType:
           type:
             - array
@@ -5301,7 +5312,7 @@ components:
             Prefer the highest-performance type the operation supports: bulk_load (Snowflake, Google BigQuery, Microsoft SQL Server on a cloud connection, Azure Synapse and Amazon Redshift — handles INSERT, upsert via `bulkLoad.primaryKeys`, and custom merge or ignore-existing logic via `bulkLoad.overrideMergeQuery`), then bulk_insert for pure INSERTs, then per_page, then per_record only when the logic cannot be expressed as a batch operation.
             For UPDATE, UPSERT, or ignore-existing logic on databases without bulk_load support, use per_page or per_record with `query` — bulk_insert has no duplicate-checking logic.
             Set a single value; do not combine types or use the legacy INSERT and UPDATE values.
-            per_page statements render against the whole batch (`batch_of_records`) rather than a single record — loop with `{{#each batch_of_records}}...{{{record.fieldName}}}...{{/each}}`.
+            per_page statements render against the whole batch (`batch_of_records`) rather than a single record — loop with `{{#each batch_of_records}}...{{record.fieldName}}...{{/each}}`, with the same quoting as `query` (double braces for strings, triple for numbers).
 
             `bulk_load` — Stages the records as files and loads them with the database's native COPY / bulk mechanism for maximum throughput; supports INSERT, upsert via bulkLoad.primaryKeys, and custom merge or ignore-existing logic via bulkLoad.overrideMergeQuery; available on Snowflake, Google BigQuery, Microsoft SQL Server (cloud connections), Azure Synapse and Amazon Redshift (NetSuite Analytics Warehouse has it through the JDBC import). The import form calls it "Use optimized bulk load (recommended for larger imports)" and, beside it, calls bulk_insert "Use batch insert SQL query".
             `bulk_insert` — Batch INSERT via multi-row VALUES clause for efficient bulk data loading; has no upsert or ignore-existing logic and is available for all RDBMS types.
@@ -5348,7 +5359,7 @@ components:
               Prompt: "Import customers, ignore existing based on email"
               ```json
               "queryType": ["per_record"],
-              "query": ["INSERT INTO customers (name, email) VALUES ('{{{record.name}}}', '{{{record.email}}}')"]
+              "query": ["INSERT INTO customers (name, email) VALUES ({{record.name}}, {{record.email}})"]
               ```
 
               ### Pure INSERT (no duplicate checking)
@@ -5362,7 +5373,7 @@ components:
               Prompt: "Update inventory counts"
               ```json
               "queryType": ["per_record"],
-              "query": ["UPDATE inventory SET qty = {{{record.qty}}} WHERE sku = '{{{record.sku}}}'"]
+              "query": ["UPDATE inventory SET qty = {{{record.qty}}} WHERE sku = {{record.sku}}"]
               ```
 
               ### Run Once Per Page
@@ -5370,7 +5381,7 @@ components:
               ```json
               "queryType": ["per_page"]
               ```
-              **per_page uses a different Handlebars context than per_record.** The context is the entire batch (`batch_of_records`), not a single `record.` object. Loop through with `{{#each batch_of_records}}...{{{record.fieldName}}}...{{/each}}`.
+              **per_page uses a different Handlebars context than per_record.** The context is the entire batch (`batch_of_records`), not a single `record.` object. Loop through with `{{#each batch_of_records}}...{{record.fieldName}}...{{/each}}`, quoting as in per_record: double braces for strings, triple braces for numbers.
 
               ### Run Once at Start
               Prompt: "Run this cleanup script before processing"
@@ -8330,8 +8341,8 @@ components:
       description: |-
         Configuration for a `ToolImport`, which executes a reusable Celigo Tool resource as the
         import action. The referenced tool defines its own input contract, processing pipeline, and
-        output; this object binds the tool to the import and optionally overrides the connections the
-        tool uses for this invocation.
+        output; this object binds the tool to the import, along with the connections the tool's steps
+        use for this invocation.
       x-celigo-ai-guidance:
         - |-
           A ToolImport is the **wrapper** that lets a flow / API / another Tool consume a
@@ -8382,7 +8393,8 @@ components:
             Per-import overrides applied to the referenced tool at execution time. Tools use a
             bring-your-own-keys connection model: the tool declares abstract connection slots, and the
             consumer binds concrete connections here so one tool definition can run against different
-            systems without being modified. Omit to run the tool with its default connections.
+            systems without being modified. Bind every connection the tool's steps use; to keep the
+            connection a step was authored against, bind it to itself.
           x-celigo-ai-guidance:
             - |-
               Per-consumer overrides applied when the wrapper invokes the underlying Tool.
@@ -8390,10 +8402,10 @@ components:
               imports each reference a `_connectionId`,
               and consumers bind real account connections to those abstract requirements here.
             - |-
-              Omit this block (or omit `connections` inside it) when the wrapper inherits the
-              Tool's authored connections as-is.
-              That's the right default when the Tool was authored against connections the
-              consumer also wants to use.
+              The save accepts a wrapper without bindings, but when the Tool's steps use connections
+              its run then fails with `connection_not_overridden`. Write one `connections` entry per
+              connection the Tool's steps use, even when the wrapper keeps the Tool's authored
+              connection (`_id` equal to `_abstractId`); a Tool whose steps use no connection needs none.
           properties:
             connections:
               type: array
@@ -9461,7 +9473,6 @@ components:
                 - gpt-5-mini
                 - gpt-5-nano
                 - gpt-4.1-mini
-                - gpt-4o
               x-celigo-ui-override: Required by the AI agent configuration form. Encoded here to mirror the form so builders produce connectable configurations.
               x-celigo-ai-guidance:
                 - |-
@@ -16188,15 +16199,16 @@ components:
             - filter
           description: |-
             Filter applied to incoming records before they are sent to the destination system.
-            Records that match continue through the import; records that don't are silently
-            dropped. Filter expressions reference the incoming record's fields.
+            Records that match continue through the import; records that don't skip this import,
+            counted as ignored, and continue to the next step. Filter expressions reference the
+            incoming record's fields.
           allOf:
             - $ref: '#/components/schemas/Filter'
           x-celigo-ai-guidance:
             - |-
               ## IMPORT-SPECIFIC BEHAVIOR
 
-              **Pre-Import Filtering**: Filters are applied to incoming records before they are sent to the destination system. Records that don't match the filter criteria are silently dropped and not imported.
+              **Pre-Import Filtering**: Filters are applied to incoming records before they are sent to the destination system. A record that doesn't match is not sent, but it is not removed from the flow: it continues to the next step without this import's response-mapped fields, so a later step that writes those fields needs its own filter.
         traceKeyTemplate:
           type: string
           x-celigo-agent:
@@ -16313,7 +16325,7 @@ components:
                   mapping step, on the raw upstream records.  Engage when the
                   user needs to reshape, validate, filter, or annotate records
                   before the mapping sees them (drop archived records,
-                  normalize date strings, split a record into many).  Don't
+                  normalize date strings).  Don't
                   engage for static value substitution or simple field
                   renames — mappings handle those.
 
@@ -16589,7 +16601,7 @@ components:
                 resultField, ...)
               - ``netsuite_da.lookups`` — NetSuite search (recordType,
                 searchField, operator, ...)
-              - ``http.lookups`` — HTTP request (method, relativeURI, postBody,
+              - ``http.lookups`` — HTTP request (method, relativeURI, body,
                 extract, ...)
               - ``jdbc.lookups`` / ``rdbms.lookups`` — SQL query (query,
                 extract, ...)
@@ -17125,8 +17137,11 @@ components:
         connectionMap:
           type: object
           description: |
-            Optional mapping of original connection ids to replacement connection ids.
+            Mapping of original connection ids to replacement connection ids.
             Keys are source connection ids on the original resource; values are target connection ids.
+            For an import that uses a connection, an empty map fails with 400
+            `invalid_connectionMap`, as it does for an export; map the connection to itself to reuse
+            it in the clone.
           additionalProperties:
             type: string
           example:

package/dist/tool.yml

@@ -12883,7 +12883,7 @@ components:
               ## EXAMPLES:
               - `{ "UserId": "12345", "Name": "John Doe", "Age": 30, "Preferences": { "Language": "en", "Notifications": true } }`
           examples:
-            - '{"id": "{{record.id}}", "name": "{{record.name}}", "total": {{record.total}}}'
+            - '{"id": "{{record.id}}", "name": "{{record.name}}", "total": {{record.total}} }'
         updateExpression:
           type: string
           x-celigo-ui-override: Required by the DynamoDB import form when method is updateItem (dynamodb.updateExpression required, visibleWhen method=updateItem).
@@ -13546,7 +13546,10 @@ components:
               the Import's mapping step runs first and shapes the source record,
               then this template renders against that mapped record.
               Reference the mapped record with the ``record`` root when wrapping it (e.g.
-              ``{"requestData": {{{jsonSerialize record}}}}``).
+              ``{"requestData": {{{jsonSerialize record}}} }``).
+              Keep a literal ``}`` apart from a closing ``}}`` or ``}}}`` (a space is enough): the save
+              accepts ``{{{jsonSerialize record}}}}``, but every record then fails with
+              ``handlebars_template_parse_error``.
               Avoid bare ``{{{jsonSerialize record}}}`` with no wrapper — leave the field undefined instead.
               Also avoid wrapping a single post-mapped scalar field in ``jsonSerialize`` (e.g.
               ``{{{jsonSerialize record.<scalar>}}}``) — that pattern is brittle.
@@ -13609,9 +13612,9 @@ components:
 
               Typical shapes:
               - Message-bus envelope:
-                ``{"MessageBody": {"class": "EntityUpdate", "payload": {{{jsonSerialize record}}}}}``
+                ``{"MessageBody": {"class": "EntityUpdate", "payload": {{{jsonSerialize record}}} }}``
               - Metadata wrap:
-                ``{"batchNumber": "{{timestamp dateTimeFormat CST}}", "interfaceType": "...", "requestData": {{{jsonSerialize record}}}}``
+                ``{"batchNumber": "{{timestamp dateTimeFormat CST}}", "interfaceType": "...", "requestData": {{{jsonSerialize record}}} }``
               - Named single-record array wrap (when destination wants ``[record]`` but each request sends one):
                 ``{"products": [{{{jsonSerialize record}}}]}``
 
@@ -13652,7 +13655,7 @@ components:
               current ``{{#each data}}`` item.
 
               Example shape:
-              ``{"header": {"sellerId": "{{connection.http.unencrypted.sellerId}}"}, "messages": [{{#each data}}{"sku": "{{sku}}", "qty": {{quantity}}}{{/each}}]}``
+              ``{"header": {"sellerId": "{{connection.http.unencrypted.sellerId}}"}, "messages": [{{#each data}}{"sku": "{{sku}}", "qty": {{quantity}} }{{/each}}]}``
             - |-
               ## Anti-pattern — DO NOT wrap a post-mapped scalar in jsonSerialize
 
@@ -13737,7 +13740,7 @@ components:
                 mix the two shapes in one body.
           examples:
             - - '{"name": "{{record.name}}", "email": "{{record.email}}"}'
-            - - '{"requestData": {{{jsonSerialize record}}}}'
+            - - '{"requestData": {{{jsonSerialize record}}} }'
             - - '{"values": [{{#each batch_of_records}}{{{jsonSerialize this.record}}}{{#unless @last}},{{/unless}}{{/each}}]}'
           x-celigo-agent:
             - handlebars
@@ -14227,9 +14230,7 @@ components:
 
             The referenced helper bundles the polling config plus a required status
             export (polled to check progress) and a result export (fetches the
-            final payload). An import configured with an async helper cannot carry
-            its own transform, output filter, or preSavePage hook — put that
-            processing in the result export instead.
+            final payload).
           examples:
             - 60a2c4e6f321d800129a1a3c
           x-celigo-agent:
@@ -14313,7 +14314,7 @@ components:
 
               - **Static** — only ``map`` + optional ``default``.  No HTTP
                 request issued.  Use for small controlled vocabularies.
-              - **Dynamic** — ``method`` + ``relativeURI`` (+ ``postBody``,
+              - **Dynamic** — ``method`` + ``relativeURI`` (+ ``body``,
                 ``headers``, ``extract``).  Issues a live HTTP request per
                 lookup.  Adds one HTTP request per record at runtime — factor
                 this into flow design for high-volume syncs.
@@ -14351,14 +14352,18 @@ components:
                   inject values from the incoming record — e.g.
                   ``/customers?email={{{email}}}`` or
                   ``/accounts/{{{accountId}}}``.
-              postBody:
+              body:
                 type: string
                 x-celigo-agent:
                   - handlebars
                 description: |
-                  Request body template for POST / PUT / PATCH lookup methods.
-                  Typically a JSON string with Handlebars placeholders —
-                  ``{"email":"{{{email}}}"}``. Ignored for GET / DELETE.
+                  Request body template for POST / PUT / PATCH lookup methods, typically
+                  a JSON string with Handlebars placeholders (``{"email":"{{{email}}}"}``);
+                  ignored for GET / DELETE. The record's fields sit at the top level:
+                  ``{{email}}`` renders the record's value, while ``{{record.email}}``
+                  renders empty.
+                x-celigo-ai-guidance:
+                  - 'Put the lookup''s request template here, not in ``postBody``: a ``postBody`` saves without an error but is not kept under ``http.lookups``, so the lookup goes out with no body and the run reports no error.'
               headers:
                 type: array
                 items:
@@ -16009,9 +16014,9 @@ components:
                                 line) to the rows that populate the
                                 subrecord.  Typically `$` when the
                                 subrecord data is carried on the same
-                                line item (the enclosing
-                                `lists[].jsonPath` has already selected
-                                the line).  Defaults to `$`.
+                                line item (iteration over the sublist
+                                has already selected the line).
+                                Defaults to `$`.
                             mapping:
                               type: object
                               description: |
@@ -16466,9 +16471,10 @@ components:
                   SQL `SELECT` statement that resolves the lookup value.
                   Typically returns a single row with a single column; use
                   `extract` to pick the column when the query returns multiple.
-                  Inject values from the incoming record with Handlebars — RDBMS
-                  queries use triple braces and the `record.` prefix:
-                  `SELECT id FROM users WHERE email = '{{{record.email}}}'`.
+                  Inject values from the incoming record with Handlebars and the
+                  `record.` prefix — double braces for strings, which the platform
+                  quotes and escapes, and triple braces for numbers:
+                  `SELECT id FROM users WHERE email = {{record.email}}`.
               extract:
                 type: string
                 description: |
@@ -16516,7 +16522,7 @@ components:
           description: |-
             SQL statements to execute; required when queryType is `["per_record"]`, `["per_page"]`, or `["first_page"]`, and typically contains a single statement.
             Each element is a complete SQL statement as a plain string — never a single bare string and never an array of objects (objects cause a Cast error).
-            Inject values from the incoming record with Handlebars using the `record.` prefix and triple braces, e.g. `'{{{record.name}}}'` for strings (single-quoted in the SQL) and `{{{record.quantity}}}` for numbers.
+            Inject values from the incoming record with Handlebars using the `record.` prefix: double braces for strings and dates (`{{record.name}}`; the platform quotes and escapes the value) and triple braces for numbers (`{{{record.quantity}}}`).
             Rendering is strict: a reference the render model cannot resolve (a bare `{{name}}` without prefix, or `record.*` when the arriving record is a grouped array) fails the step with `cannot_evaluate_handlebars` — it does not render an empty value.
             `record` and `rows` are aliases chosen by the arriving data's shape: an object record binds `record` (`rows` undefined); a grouped array-record (e.g. upstream `groupByFields`) binds `rows` (`record` undefined) — address grouped rows as `{{rows.0.field}}` or iterate `{{#each rows}}`.
             Double braces (`{{record.field}}`) output the value wrapped in single quotes with embedded quotes doubled, while triple braces output it raw; block helpers such as `{{#each}}` and `{{#if}}` use double braces as normal.
@@ -16530,7 +16536,7 @@ components:
               - CORRECT: ["INSERT INTO users (name, email) VALUES ({{record.name}}, {{record.email}})"]
               - WRONG: "INSERT INTO users ..."  (not an array)
               - WRONG: [{"query": "INSERT INTO users ..."}]  (objects are invalid — causes Cast error)
-              - WRONG: ["INSERT INTO users (name) VALUES ('{{name}}')"]  (missing record. prefix — rendering is strict, so the step fails with cannot_evaluate_handlebars)
+              - WRONG: ["INSERT INTO users (name) VALUES ({{name}})"]  (missing record. prefix — rendering is strict, so the step fails with cannot_evaluate_handlebars)
             - |-
               ## RDBMS HANDLEBARS SYNTAX
 
@@ -16564,7 +16570,7 @@ components:
                 | Numeric column value (INT, DECIMAL, ...) | `{{{record.field}}}`    |
                 | Stored procedure raw arg (already typed) | `{{{record.field}}}`    |
                 | Identifier (table/column name)           | `{{{record.field}}}`    |
-                | JSON literal (`PARSE_JSON`/JSONB)      | `{{{jsonSerialize record.subobject}}}` |
+                | JSON literal (`PARSE_JSON`/JSONB)      | `{{jsonSerialize record.subobject}}` (renders the JSON as a quoted string) |
 
               - **Block helpers** (`{{#each}}`, `{{#if}}`, `{{/each}}`,
                 `{{#unless}}`) use double braces as normal — they emit no value.
@@ -16583,7 +16589,7 @@ components:
               - Per-page batch (different Handlebars context — see `queryType: per_page` below): `["{{#each batch_of_records}}UPDATE staging SET done=1 WHERE id={{{this.record.id}}};{{/each}}"]`
           examples:
             - - INSERT INTO orders (id, total) VALUES ({{{record.id}}}, {{{record.total}}})
-            - - '{{#each batch_of_records}}UPDATE customers SET name=''{{{record.name}}}'' WHERE id={{{record.id}}};{{/each}}'
+            - - '{{#each batch_of_records}}UPDATE customers SET name={{record.name}} WHERE id={{{record.id}}};{{/each}}'
         queryType:
           type:
             - array
@@ -16612,7 +16618,7 @@ components:
             Prefer the highest-performance type the operation supports: bulk_load (Snowflake, Google BigQuery, Microsoft SQL Server on a cloud connection, Azure Synapse and Amazon Redshift — handles INSERT, upsert via `bulkLoad.primaryKeys`, and custom merge or ignore-existing logic via `bulkLoad.overrideMergeQuery`), then bulk_insert for pure INSERTs, then per_page, then per_record only when the logic cannot be expressed as a batch operation.
             For UPDATE, UPSERT, or ignore-existing logic on databases without bulk_load support, use per_page or per_record with `query` — bulk_insert has no duplicate-checking logic.
             Set a single value; do not combine types or use the legacy INSERT and UPDATE values.
-            per_page statements render against the whole batch (`batch_of_records`) rather than a single record — loop with `{{#each batch_of_records}}...{{{record.fieldName}}}...{{/each}}`.
+            per_page statements render against the whole batch (`batch_of_records`) rather than a single record — loop with `{{#each batch_of_records}}...{{record.fieldName}}...{{/each}}`, with the same quoting as `query` (double braces for strings, triple for numbers).
 
             `bulk_load` — Stages the records as files and loads them with the database's native COPY / bulk mechanism for maximum throughput; supports INSERT, upsert via bulkLoad.primaryKeys, and custom merge or ignore-existing logic via bulkLoad.overrideMergeQuery; available on Snowflake, Google BigQuery, Microsoft SQL Server (cloud connections), Azure Synapse and Amazon Redshift (NetSuite Analytics Warehouse has it through the JDBC import). The import form calls it "Use optimized bulk load (recommended for larger imports)" and, beside it, calls bulk_insert "Use batch insert SQL query".
             `bulk_insert` — Batch INSERT via multi-row VALUES clause for efficient bulk data loading; has no upsert or ignore-existing logic and is available for all RDBMS types.
@@ -16659,7 +16665,7 @@ components:
               Prompt: "Import customers, ignore existing based on email"
               ```json
               "queryType": ["per_record"],
-              "query": ["INSERT INTO customers (name, email) VALUES ('{{{record.name}}}', '{{{record.email}}}')"]
+              "query": ["INSERT INTO customers (name, email) VALUES ({{record.name}}, {{record.email}})"]
               ```
 
               ### Pure INSERT (no duplicate checking)
@@ -16673,7 +16679,7 @@ components:
               Prompt: "Update inventory counts"
               ```json
               "queryType": ["per_record"],
-              "query": ["UPDATE inventory SET qty = {{{record.qty}}} WHERE sku = '{{{record.sku}}}'"]
+              "query": ["UPDATE inventory SET qty = {{{record.qty}}} WHERE sku = {{record.sku}}"]
               ```
 
               ### Run Once Per Page
@@ -16681,7 +16687,7 @@ components:
               ```json
               "queryType": ["per_page"]
               ```
-              **per_page uses a different Handlebars context than per_record.** The context is the entire batch (`batch_of_records`), not a single `record.` object. Loop through with `{{#each batch_of_records}}...{{{record.fieldName}}}...{{/each}}`.
+              **per_page uses a different Handlebars context than per_record.** The context is the entire batch (`batch_of_records`), not a single `record.` object. Loop through with `{{#each batch_of_records}}...{{record.fieldName}}...{{/each}}`, quoting as in per_record: double braces for strings, triple braces for numbers.
 
               ### Run Once at Start
               Prompt: "Run this cleanup script before processing"
@@ -19641,8 +19647,8 @@ components:
       description: |-
         Configuration for a `ToolImport`, which executes a reusable Celigo Tool resource as the
         import action. The referenced tool defines its own input contract, processing pipeline, and
-        output; this object binds the tool to the import and optionally overrides the connections the
-        tool uses for this invocation.
+        output; this object binds the tool to the import, along with the connections the tool's steps
+        use for this invocation.
       x-celigo-ai-guidance:
         - |-
           A ToolImport is the **wrapper** that lets a flow / API / another Tool consume a
@@ -19693,7 +19699,8 @@ components:
             Per-import overrides applied to the referenced tool at execution time. Tools use a
             bring-your-own-keys connection model: the tool declares abstract connection slots, and the
             consumer binds concrete connections here so one tool definition can run against different
-            systems without being modified. Omit to run the tool with its default connections.
+            systems without being modified. Bind every connection the tool's steps use; to keep the
+            connection a step was authored against, bind it to itself.
           x-celigo-ai-guidance:
             - |-
               Per-consumer overrides applied when the wrapper invokes the underlying Tool.
@@ -19701,10 +19708,10 @@ components:
               imports each reference a `_connectionId`,
               and consumers bind real account connections to those abstract requirements here.
             - |-
-              Omit this block (or omit `connections` inside it) when the wrapper inherits the
-              Tool's authored connections as-is.
-              That's the right default when the Tool was authored against connections the
-              consumer also wants to use.
+              The save accepts a wrapper without bindings, but when the Tool's steps use connections
+              its run then fails with `connection_not_overridden`. Write one `connections` entry per
+              connection the Tool's steps use, even when the wrapper keeps the Tool's authored
+              connection (`_id` equal to `_abstractId`); a Tool whose steps use no connection needs none.
           properties:
             connections:
               type: array
@@ -20772,7 +20779,6 @@ components:
                 - gpt-5-mini
                 - gpt-5-nano
                 - gpt-4.1-mini
-                - gpt-4o
               x-celigo-ui-override: Required by the AI agent configuration form. Encoded here to mirror the form so builders produce connectable configurations.
               x-celigo-ai-guidance:
                 - |-
@@ -25057,15 +25063,16 @@ components:
             - filter
           description: |-
             Filter applied to incoming records before they are sent to the destination system.
-            Records that match continue through the import; records that don't are silently
-            dropped. Filter expressions reference the incoming record's fields.
+            Records that match continue through the import; records that don't skip this import,
+            counted as ignored, and continue to the next step. Filter expressions reference the
+            incoming record's fields.
           allOf:
             - $ref: '#/components/schemas/Filter'
           x-celigo-ai-guidance:
             - |-
               ## IMPORT-SPECIFIC BEHAVIOR
 
-              **Pre-Import Filtering**: Filters are applied to incoming records before they are sent to the destination system. Records that don't match the filter criteria are silently dropped and not imported.
+              **Pre-Import Filtering**: Filters are applied to incoming records before they are sent to the destination system. A record that doesn't match is not sent, but it is not removed from the flow: it continues to the next step without this import's response-mapped fields, so a later step that writes those fields needs its own filter.
         traceKeyTemplate:
           type: string
           x-celigo-agent:
@@ -25182,7 +25189,7 @@ components:
                   mapping step, on the raw upstream records.  Engage when the
                   user needs to reshape, validate, filter, or annotate records
                   before the mapping sees them (drop archived records,
-                  normalize date strings, split a record into many).  Don't
+                  normalize date strings).  Don't
                   engage for static value substitution or simple field
                   renames — mappings handle those.
 
@@ -25458,7 +25465,7 @@ components:
                 resultField, ...)
               - ``netsuite_da.lookups`` — NetSuite search (recordType,
                 searchField, operator, ...)
-              - ``http.lookups`` — HTTP request (method, relativeURI, postBody,
+              - ``http.lookups`` — HTTP request (method, relativeURI, body,
                 extract, ...)
               - ``jdbc.lookups`` / ``rdbms.lookups`` — SQL query (query,
                 extract, ...)
@@ -29806,7 +29813,7 @@ components:
             Selects which files are processed: files matching the filter criteria are exported,
             and non-matching files are skipped entirely before processing begins. Filterable
             fields come from each file's metadata — most providers expose filename, filesize,
-            and lastmodified (e.g. ["endswith", ["extract", "filename"], ".csv"]).
+            and lastmodified (e.g. ["endswith", ["string", ["extract", "filename"]], ".csv"]).
           allOf:
             - $ref: '#/components/schemas/Filter'
           x-celigo-ai-guidance:
@@ -29821,7 +29828,7 @@ components:
 
               1. **filename**: The name of the file (with extension)
                 - Example filter: Match files with specific extensions or naming patterns
-                - Usage: `["endswith", ["extract", "filename"], ".csv"]`
+                - Usage: `["endswith", ["string", ["extract", "filename"]], ".csv"]`
 
               2. **filesize**: The size of the file in bytes
                 - Example filter: Skip files that are too large or too small
@@ -29829,7 +29836,7 @@ components:
 
               3. **lastmodified**: The last modification timestamp of the file
                 - Example filter: Process only files created/modified within a specific date range
-                - Usage: `["greaterthan", ["extract", "lastmodified"], "2023-01-01T00:00:00Z"]`
+                - Usage: `["greaterthan", ["epochtime", ["extract", "lastmodified"]], 1672531200000]` (2023-01-01T00:00:00Z in epoch milliseconds)
         backupPath:
           type: string
           description: Path where backup copies of source files are stored before processing.
@@ -30090,38 +30097,10 @@ components:
         bearerToken:
           type: string
           description: |-
-            Bearer token used to authenticate inbound distributed export requests. Optional — most
-            distributed listeners (NetSuite, Salesforce real-time) use no token. Write-only and stored
-            encrypted; treat it as a sensitive credential.
-          x-celigo-ai-guidance:
-            - |-
-              ## FIELD BEHAVIOR
-
-              This token provides authentication for the distributed export:
-
-              - Required for secure access to distributed endpoints
-              - Must be a valid bearer token format
-              - Used in Authorization header as "Bearer {token}"
-              - Should be kept secure and rotated regularly
-            - |-
-              ## IMPLEMENTATION GUIDANCE
-
-              ### Token management
-
-              - Store tokens securely (encrypted at rest)
-              - Implement token rotation policies
-              - Monitor token expiration dates
-              - Use environment variables for token storage
-
-              ### Security considerations
-
-              - Never log bearer tokens in plain text
-              - Implement proper access controls
-              - Use HTTPS for all token transmissions
-              - Validate tokens on each request
-
-              IMPORTANT: Bearer tokens provide full access to the distributed export.
-              Treat them as sensitive credentials.
+            Bearer token that a system pushing data into this export sends as
+            `Authorization: Bearer <token>`. Optional — most distributed listeners (NetSuite,
+            Salesforce real-time) use no token. Write-only and stored encrypted; treat it as a
+            sensitive credential.
           format: password
           examples:
             - eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
@@ -30517,7 +30496,7 @@ components:
               (`http.paging.body` likewise from its paging fields). A body that is not parseable JSON at
               rest — Handlebars block helpers outside a string value — renders every field EMPTY in that
               form, so keep templated variables inside a JSON string value:
-              `"variables": "{\"after\": {{#if export.http.paging.token}}\"{{export.http.paging.token}}\"{{else}}null{{/if}}}"`.
+              `"variables": "{\"after\": {{#if export.http.paging.token}}\"{{export.http.paging.token}}\"{{else}}null{{/if}} }"`.
             - |-
               The GraphQL form has no relative URI field: the connection `baseURI` is expected to be the
               GraphQL endpoint (a saved `relativeURI` still applies but is not shown). Create GraphQL
@@ -36694,9 +36673,10 @@ components:
 
         In a flow test run, and for an upstream lookup during a page-processor preview
         (`previewPageProcessor`), integrator.io substitutes this mock output for the export's live
-        response instead of calling the source. It is not substituted anywhere else: a target lookup
-        in that preview runs its live query, `POST /v1/exports/preview` calls the source, and real
-        runs ignore it. This allows you to:
+        response instead of calling the source. A saved mock is not read anywhere else: a target
+        lookup in that preview runs its live query, invoking the export
+        (`POST /v1/exports/{_id}/invoke`) reads the source, and real runs ignore it. This allows you
+        to:
         - Test mappings with representative data
         - Configure downstream flow steps without waiting for real data
         - Simulate various data scenarios
@@ -36705,6 +36685,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.
 
+        `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
+        the source; remove `mockOutput` from the body to preview live records.
+
         **Limitations**
 
         - Maximum of 10 records
@@ -36722,8 +36707,8 @@ components:
           the stored shape walks paths that do not exist at runtime.
         - |-
           A saved mockOutput is read in exactly two places — a flow test run, and an upstream lookup
-          during a page-processor preview. A target lookup's preview, `POST /v1/exports/preview` and
-          every real run call the source and never read it.
+          during a page-processor preview. A target lookup's preview, `POST /v1/exports/{_id}/invoke`
+          and every real run call the source and never read it.
       properties:
         page_of_records:
           type: array
@@ -37165,9 +37150,9 @@ components:
           x-celigo-agent:
             - filter
           description: |-
-            Filter applied to records immediately after they are retrieved from the source.
-            Records that match continue through the flow; records that don't are silently dropped.
-            Filter expressions reference the exported record's own fields.
+            Filter applied to each record after the export's transform and before its preSavePage
+            hook. Records that match continue through the flow; records that don't are silently
+            dropped. Filter expressions reference the transformed record's fields.
           allOf:
             - $ref: '#/components/schemas/Filter'
           x-celigo-ai-guidance:
@@ -37177,13 +37162,13 @@ components:
 
               ## FILTER BEHAVIOR
 
-              When configured, the filter is applied immediately after records are retrieved from the source system:
+              When configured, the filter is applied to each record after the export's transform and before the preSavePage hook:
               - Records that match the filter criteria continue through the flow
               - Records that don't match are silently dropped
               - No partial record processing is performed
 
               ## AVAILABLE FILTER FIELDS
-              The fields available for filtering are the data fields from each record retrieved by the export.
+              The fields available for filtering are those of each record as the export's transform leaves it (the retrieved record when no transform is set).
         inputFilter:
           x-celigo-agent:
             - filter
@@ -37296,9 +37281,12 @@ components:
               x-celigo-agent:
                 - script
               description: |-
-                Hook that runs after each page of records is retrieved from the source but before it
-                is sent to downstream steps. Commonly used to flatten structures, drop unwanted
-                records, or add computed fields.
+                Hook that runs on each page of records after the export's transform and output
+                filter, before the page is sent to downstream steps; commonly used to flatten
+                structures, drop unwanted records, or add computed fields. It receives the page as
+                `options.data` (with `errors`, `pageIndex`, `configuration` and `settings`) and returns
+                `{data, errors, abort, newErrorsAndRetryData}`. An exception thrown here fails every
+                record on that page, each with its own retry data, and later pages still run.
               properties:
                 function:
                   type: string

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@celigo/api-specs",
-  "version": "0.2.132",
+  "version": "0.2.134",
   "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": "9f942658",
+		"iasCommit": "86f54b3d",
 		"generatedAt": "2026-10-21"
 	},
 	"roots": {
@@ -6674,13 +6674,13 @@
 			"p": {
 				"_lookupCacheId": 1,
 				"allowFailures": 118,
+				"body": 1,
 				"default": 88,
 				"extract": 1,
 				"headers": 260,
 				"map": 117,
 				"method": 164,
 				"name": 1,
-				"postBody": 1,
 				"relativeURI": 1,
 				"useDefaultOnMultipleMatches": 9
 			}