@celigo/api-specs 0.2.159 → 0.2.160

package/dist/ai-agent.yml

@@ -4589,6 +4589,10 @@ components:
         - Items that don't match are completely skipped
         - No partial processing is performed
 
+        Send the whole object. A rules array sent alone as the `filter` value is not
+        stored, and a full update of an export that carries one removes the filter the
+        export had, with no error.
+
         **Implementation approaches**
 
         There are two distinct filtering mechanisms available:
@@ -4739,6 +4743,8 @@ components:
                 **Using `extract` to access record fields:**
                 - Retrieves values from the current record being processed
                 - Can access nested properties using dot notation (e.g., `"customer.email"`)
+                - Paths are relative to the record itself: `["extract", "record.status"]`
+                  matches nothing
                 - In a record filter, must be wrapped in a type conversion (`string`, `number`,
                   `boolean` or `epochtime`): a bare `["extract", ...]` operand is refused with 422
                   "Field operation extract must be called by a Type Conversion Operation but was called
@@ -4749,9 +4755,17 @@ components:
                 - Retrieves values from the integration's configuration settings
                 - Supports different scopes with prefix notation:
                   - `flow.settingName`: Access flow-level settings
-                  - `export.settingName`: Access export-level settings
-                  - `import.settingName`: Access import-level settings
+                  - `flowGrouping.settingName`: Access the flow group's settings
+                  - `export.settingName`: Access the export's (or lookup's) own settings
+                  - `import.settingName`: Access the import's own settings
                   - `integration.settingName`: Access integration-level settings
+                  - `connection.settingName`, `iClient.settingName`: Access the step's
+                    connection and iClient settings
+                - A scope whose resource has no settings can be absent; a rule that reads
+                  it matches nothing
+                - Must be wrapped in a type conversion like `extract`: a bare
+                  `["settings", ...]` operand is refused with 422 "Field operation settings
+                  must be called by a Type Conversion Operation"
                 - Useful for dynamic filtering based on configuration
 
                 **Field Transformations**
@@ -4761,6 +4775,24 @@ components:
                 - `"floor"`: Round number down to the nearest integer
                 - `"abs"`: Get absolute value of a number
 
+                **Arithmetic** (number operands)
+                - `"add"`, `"subtract"`, `"multiply"`, `"divide"`, `"modulo"`: for example
+                  `["subtract", ["number", ["extract", "total"]], ["number", ["extract", "discount"]]]`.
+                  `mod` is not an operator (422 "Invalid operation: mod.").
+
+                **Dates**
+                - `epochtime` reads ISO 8601 strings and epoch-millisecond numbers. An empty
+                  string, a string that isn't a date, or epoch milliseconds sent as a string
+                  fail it with "Invalid date. Cannot convert given string or number to date
+                  time.", followed by `; record=` and the record as JSON: in a run that record fails (`FILTER_EVALUATION_FAILED`, source
+                  `output_filter` on an export), and `POST /v1/processors/filter` and an
+                  export preview refuse the whole call with 422. `and` and `or` evaluate
+                  every operand, so a `notempty` test beside it doesn't prevent the failure.
+                  A missing or null field doesn't match.
+                - `datetime`, `date` and `timestamp` are not type conversions: 422
+                  "Invalid operation: <name>."
+                - `number` reads a missing or empty field as 0.
+
                 **Handlebars operands**
                 - An operand can also be a string holding exactly one Handlebars expression, such as
                   `"{{record.status}}"` or `"{{lowercase record.code}}"`, on either side of the
@@ -4772,6 +4804,12 @@ components:
                   with 422 "invalid datetime format".
                 - A string with text around the expression, or with more than one expression, is
                   compared as a literal.
+                - `["number", "{{timestamp \"x\"}}"]` is the current time in epoch milliseconds,
+                  so `["greaterthanequals", ["epochtime", ["extract", "created"]], ["subtract",
+                  ["number", "{{timestamp \"x\"}}"], 604800000]]` keeps records created in the
+                  last 7 days.
+                - An unknown helper fails the rule with 422 "Failed to evaluate handlebars
+                  expression".
 
                 Choose the type conversion that matches the comparison — `number` for numeric
                 comparisons, `epochtime` for dates, `string` for text. For example:

package/dist/export.yml

@@ -489,9 +489,10 @@ paths:
 
         Use `test.limit` inside the body to cap the number of records
         returned. Configuration errors in the export doc surface in the
-        `errors[]` and `stages[].errors[]` arrays within a 200 response;
-        only structural validation failures (e.g. missing `_connectionId`)
-        return 4xx.
+        `errors[]` and `stages[].errors[]` arrays within a 200 response, but
+        not every failure does: structural validation failures (e.g. missing
+        `_connectionId`) return 4xx, and so does an output filter that can't
+        read a record's value (see the 422 response).
       requestBody:
         required: true
         content:
@@ -522,7 +523,8 @@ paths:
       responses:
         '200':
           description: |-
-            Preview envelope — always returned on valid-body calls. User-error in
+            Preview envelope for a preview that ran; a valid body can still answer
+            422 (see that response). User-error in
             the export config (handlebars template failures, runtime errors)
             surfaces in `errors[]` and `stages[].errors[]`; inspect those before
             trusting `stages[].data[]`.
@@ -553,7 +555,11 @@ paths:
           description: |-
             Structural validation failed — typically `missing_required_field`
             for fields the preview pipeline needs before it can execute
-            (e.g. `_connectionId`).
+            (e.g. `_connectionId`). A valid output filter also fails the preview
+            with 422 when a record holds a value its type conversion can't read,
+            such as an empty or non-date string under `epochtime`: the message is
+            "Invalid date. Cannot convert given string or number to date time.",
+            followed by `; record=` and that record as JSON.
           content:
             application/json:
               schema:
@@ -2775,6 +2781,10 @@ components:
         - Items that don't match are completely skipped
         - No partial processing is performed
 
+        Send the whole object. A rules array sent alone as the `filter` value is not
+        stored, and a full update of an export that carries one removes the filter the
+        export had, with no error.
+
         **Implementation approaches**
 
         There are two distinct filtering mechanisms available:
@@ -2925,6 +2935,8 @@ components:
                 **Using `extract` to access record fields:**
                 - Retrieves values from the current record being processed
                 - Can access nested properties using dot notation (e.g., `"customer.email"`)
+                - Paths are relative to the record itself: `["extract", "record.status"]`
+                  matches nothing
                 - In a record filter, must be wrapped in a type conversion (`string`, `number`,
                   `boolean` or `epochtime`): a bare `["extract", ...]` operand is refused with 422
                   "Field operation extract must be called by a Type Conversion Operation but was called
@@ -2935,9 +2947,17 @@ components:
                 - Retrieves values from the integration's configuration settings
                 - Supports different scopes with prefix notation:
                   - `flow.settingName`: Access flow-level settings
-                  - `export.settingName`: Access export-level settings
-                  - `import.settingName`: Access import-level settings
+                  - `flowGrouping.settingName`: Access the flow group's settings
+                  - `export.settingName`: Access the export's (or lookup's) own settings
+                  - `import.settingName`: Access the import's own settings
                   - `integration.settingName`: Access integration-level settings
+                  - `connection.settingName`, `iClient.settingName`: Access the step's
+                    connection and iClient settings
+                - A scope whose resource has no settings can be absent; a rule that reads
+                  it matches nothing
+                - Must be wrapped in a type conversion like `extract`: a bare
+                  `["settings", ...]` operand is refused with 422 "Field operation settings
+                  must be called by a Type Conversion Operation"
                 - Useful for dynamic filtering based on configuration
 
                 **Field Transformations**
@@ -2947,6 +2967,24 @@ components:
                 - `"floor"`: Round number down to the nearest integer
                 - `"abs"`: Get absolute value of a number
 
+                **Arithmetic** (number operands)
+                - `"add"`, `"subtract"`, `"multiply"`, `"divide"`, `"modulo"`: for example
+                  `["subtract", ["number", ["extract", "total"]], ["number", ["extract", "discount"]]]`.
+                  `mod` is not an operator (422 "Invalid operation: mod.").
+
+                **Dates**
+                - `epochtime` reads ISO 8601 strings and epoch-millisecond numbers. An empty
+                  string, a string that isn't a date, or epoch milliseconds sent as a string
+                  fail it with "Invalid date. Cannot convert given string or number to date
+                  time.", followed by `; record=` and the record as JSON: in a run that record fails (`FILTER_EVALUATION_FAILED`, source
+                  `output_filter` on an export), and `POST /v1/processors/filter` and an
+                  export preview refuse the whole call with 422. `and` and `or` evaluate
+                  every operand, so a `notempty` test beside it doesn't prevent the failure.
+                  A missing or null field doesn't match.
+                - `datetime`, `date` and `timestamp` are not type conversions: 422
+                  "Invalid operation: <name>."
+                - `number` reads a missing or empty field as 0.
+
                 **Handlebars operands**
                 - An operand can also be a string holding exactly one Handlebars expression, such as
                   `"{{record.status}}"` or `"{{lowercase record.code}}"`, on either side of the
@@ -2958,6 +2996,12 @@ components:
                   with 422 "invalid datetime format".
                 - A string with text around the expression, or with more than one expression, is
                   compared as a literal.
+                - `["number", "{{timestamp \"x\"}}"]` is the current time in epoch milliseconds,
+                  so `["greaterthanequals", ["epochtime", ["extract", "created"]], ["subtract",
+                  ["number", "{{timestamp \"x\"}}"], 604800000]]` keeps records created in the
+                  last 7 days.
+                - An unknown helper fails the rule with 422 "Failed to evaluate handlebars
+                  expression".
 
                 Choose the type conversion that matches the comparison — `number` for numeric
                 comparisons, `epochtime` for dates, `string` for text. For example:
@@ -17329,8 +17373,8 @@ components:
           type: array
           description: |-
             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.
+            stage, without the wrappers the transform, filter and hook stages put
+            around it, so records the export's output filter dropped are not here.
             Absent from the zero-record answers described under `stages`.
           items: {}
         dataURIs:
@@ -17351,13 +17395,17 @@ components:
           type: array
           description: |-
             Ordered list of pipeline stages the preview traversed. The preview
-            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`
-            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[]`
+            runs the export's pipeline, not just the parse: `request` and `raw`
+            for HTTP exports; `parse` for a live read that returned records, and
+            as the only stage when a `mockOutput` in the request body answers;
+            `group` when the export groups records (grouped records are bare
+            arrays of the grouped rows). After a live `parse`, the stages the
+            export configures follow: the transform (`transformTwoDotZero` for
+            Transformation 2.0 rules, `transform` for version 1 rules), the
+            output filter (`outputFilter`, where each record it drops carries
+            `isIgnored: true`) and the preSavePage hook (`preSavePageHook`, which
+            receives only the records the filter kept). Top-level `data` holds
+            the records the last of them kept, unwrapped. 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`
@@ -17369,11 +17417,15 @@ components:
             properties:
               name:
                 type: string
-                description: Stage identifier (e.g. `parse`, `request`, `raw`).
+                description: Stage identifier (e.g. `request`, `raw`, `parse`, `transformTwoDotZero`, `outputFilter`, `preSavePageHook`).
               data:
                 description: |-
                   Stage output. Shape varies — `raw` carries the source
                   response, `parse` (and `group`) carry the extracted records.
+                  The transform and `outputFilter` stages carry one
+                  `{data, errors}` entry per record (a dropped record adds
+                  `isIgnored: true`), and `preSavePageHook` one entry for the
+                  page: the object the hook returned.
                 oneOf:
                   - title: Array
                     type: array

package/dist/flow.yml

@@ -8355,8 +8355,8 @@ components:
           type: array
           description: |-
             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.
+            stage, without the wrappers the transform, filter and hook stages put
+            around it, so records the export's output filter dropped are not here.
             Absent from the zero-record answers described under `stages`.
           items: {}
         dataURIs:
@@ -8377,13 +8377,17 @@ components:
           type: array
           description: |-
             Ordered list of pipeline stages the preview traversed. The preview
-            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`
-            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[]`
+            runs the export's pipeline, not just the parse: `request` and `raw`
+            for HTTP exports; `parse` for a live read that returned records, and
+            as the only stage when a `mockOutput` in the request body answers;
+            `group` when the export groups records (grouped records are bare
+            arrays of the grouped rows). After a live `parse`, the stages the
+            export configures follow: the transform (`transformTwoDotZero` for
+            Transformation 2.0 rules, `transform` for version 1 rules), the
+            output filter (`outputFilter`, where each record it drops carries
+            `isIgnored: true`) and the preSavePage hook (`preSavePageHook`, which
+            receives only the records the filter kept). Top-level `data` holds
+            the records the last of them kept, unwrapped. 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`
@@ -8395,11 +8399,15 @@ components:
             properties:
               name:
                 type: string
-                description: Stage identifier (e.g. `parse`, `request`, `raw`).
+                description: Stage identifier (e.g. `request`, `raw`, `parse`, `transformTwoDotZero`, `outputFilter`, `preSavePageHook`).
               data:
                 description: |-
                   Stage output. Shape varies — `raw` carries the source
                   response, `parse` (and `group`) carry the extracted records.
+                  The transform and `outputFilter` stages carry one
+                  `{data, errors}` entry per record (a dropped record adds
+                  `isIgnored: true`), and `preSavePageHook` one entry for the
+                  page: the object the hook returned.
                 oneOf:
                   - title: Array
                     type: array

package/dist/httpconnector.yml

@@ -1174,6 +1174,10 @@ components:
         - Items that don't match are completely skipped
         - No partial processing is performed
 
+        Send the whole object. A rules array sent alone as the `filter` value is not
+        stored, and a full update of an export that carries one removes the filter the
+        export had, with no error.
+
         **Implementation approaches**
 
         There are two distinct filtering mechanisms available:
@@ -1324,6 +1328,8 @@ components:
                 **Using `extract` to access record fields:**
                 - Retrieves values from the current record being processed
                 - Can access nested properties using dot notation (e.g., `"customer.email"`)
+                - Paths are relative to the record itself: `["extract", "record.status"]`
+                  matches nothing
                 - In a record filter, must be wrapped in a type conversion (`string`, `number`,
                   `boolean` or `epochtime`): a bare `["extract", ...]` operand is refused with 422
                   "Field operation extract must be called by a Type Conversion Operation but was called
@@ -1334,9 +1340,17 @@ components:
                 - Retrieves values from the integration's configuration settings
                 - Supports different scopes with prefix notation:
                   - `flow.settingName`: Access flow-level settings
-                  - `export.settingName`: Access export-level settings
-                  - `import.settingName`: Access import-level settings
+                  - `flowGrouping.settingName`: Access the flow group's settings
+                  - `export.settingName`: Access the export's (or lookup's) own settings
+                  - `import.settingName`: Access the import's own settings
                   - `integration.settingName`: Access integration-level settings
+                  - `connection.settingName`, `iClient.settingName`: Access the step's
+                    connection and iClient settings
+                - A scope whose resource has no settings can be absent; a rule that reads
+                  it matches nothing
+                - Must be wrapped in a type conversion like `extract`: a bare
+                  `["settings", ...]` operand is refused with 422 "Field operation settings
+                  must be called by a Type Conversion Operation"
                 - Useful for dynamic filtering based on configuration
 
                 **Field Transformations**
@@ -1346,6 +1360,24 @@ components:
                 - `"floor"`: Round number down to the nearest integer
                 - `"abs"`: Get absolute value of a number
 
+                **Arithmetic** (number operands)
+                - `"add"`, `"subtract"`, `"multiply"`, `"divide"`, `"modulo"`: for example
+                  `["subtract", ["number", ["extract", "total"]], ["number", ["extract", "discount"]]]`.
+                  `mod` is not an operator (422 "Invalid operation: mod.").
+
+                **Dates**
+                - `epochtime` reads ISO 8601 strings and epoch-millisecond numbers. An empty
+                  string, a string that isn't a date, or epoch milliseconds sent as a string
+                  fail it with "Invalid date. Cannot convert given string or number to date
+                  time.", followed by `; record=` and the record as JSON: in a run that record fails (`FILTER_EVALUATION_FAILED`, source
+                  `output_filter` on an export), and `POST /v1/processors/filter` and an
+                  export preview refuse the whole call with 422. `and` and `or` evaluate
+                  every operand, so a `notempty` test beside it doesn't prevent the failure.
+                  A missing or null field doesn't match.
+                - `datetime`, `date` and `timestamp` are not type conversions: 422
+                  "Invalid operation: <name>."
+                - `number` reads a missing or empty field as 0.
+
                 **Handlebars operands**
                 - An operand can also be a string holding exactly one Handlebars expression, such as
                   `"{{record.status}}"` or `"{{lowercase record.code}}"`, on either side of the
@@ -1357,6 +1389,12 @@ components:
                   with 422 "invalid datetime format".
                 - A string with text around the expression, or with more than one expression, is
                   compared as a literal.
+                - `["number", "{{timestamp \"x\"}}"]` is the current time in epoch milliseconds,
+                  so `["greaterthanequals", ["epochtime", ["extract", "created"]], ["subtract",
+                  ["number", "{{timestamp \"x\"}}"], 604800000]]` keeps records created in the
+                  last 7 days.
+                - An unknown helper fails the rule with 422 "Failed to evaluate handlebars
+                  expression".
 
                 Choose the type conversion that matches the comparison — `number` for numeric
                 comparisons, `epochtime` for dates, `string` for text. For example:

package/dist/httpconnectorresource.yml

@@ -620,6 +620,10 @@ components:
         - Items that don't match are completely skipped
         - No partial processing is performed
 
+        Send the whole object. A rules array sent alone as the `filter` value is not
+        stored, and a full update of an export that carries one removes the filter the
+        export had, with no error.
+
         **Implementation approaches**
 
         There are two distinct filtering mechanisms available:
@@ -770,6 +774,8 @@ components:
                 **Using `extract` to access record fields:**
                 - Retrieves values from the current record being processed
                 - Can access nested properties using dot notation (e.g., `"customer.email"`)
+                - Paths are relative to the record itself: `["extract", "record.status"]`
+                  matches nothing
                 - In a record filter, must be wrapped in a type conversion (`string`, `number`,
                   `boolean` or `epochtime`): a bare `["extract", ...]` operand is refused with 422
                   "Field operation extract must be called by a Type Conversion Operation but was called
@@ -780,9 +786,17 @@ components:
                 - Retrieves values from the integration's configuration settings
                 - Supports different scopes with prefix notation:
                   - `flow.settingName`: Access flow-level settings
-                  - `export.settingName`: Access export-level settings
-                  - `import.settingName`: Access import-level settings
+                  - `flowGrouping.settingName`: Access the flow group's settings
+                  - `export.settingName`: Access the export's (or lookup's) own settings
+                  - `import.settingName`: Access the import's own settings
                   - `integration.settingName`: Access integration-level settings
+                  - `connection.settingName`, `iClient.settingName`: Access the step's
+                    connection and iClient settings
+                - A scope whose resource has no settings can be absent; a rule that reads
+                  it matches nothing
+                - Must be wrapped in a type conversion like `extract`: a bare
+                  `["settings", ...]` operand is refused with 422 "Field operation settings
+                  must be called by a Type Conversion Operation"
                 - Useful for dynamic filtering based on configuration
 
                 **Field Transformations**
@@ -792,6 +806,24 @@ components:
                 - `"floor"`: Round number down to the nearest integer
                 - `"abs"`: Get absolute value of a number
 
+                **Arithmetic** (number operands)
+                - `"add"`, `"subtract"`, `"multiply"`, `"divide"`, `"modulo"`: for example
+                  `["subtract", ["number", ["extract", "total"]], ["number", ["extract", "discount"]]]`.
+                  `mod` is not an operator (422 "Invalid operation: mod.").
+
+                **Dates**
+                - `epochtime` reads ISO 8601 strings and epoch-millisecond numbers. An empty
+                  string, a string that isn't a date, or epoch milliseconds sent as a string
+                  fail it with "Invalid date. Cannot convert given string or number to date
+                  time.", followed by `; record=` and the record as JSON: in a run that record fails (`FILTER_EVALUATION_FAILED`, source
+                  `output_filter` on an export), and `POST /v1/processors/filter` and an
+                  export preview refuse the whole call with 422. `and` and `or` evaluate
+                  every operand, so a `notempty` test beside it doesn't prevent the failure.
+                  A missing or null field doesn't match.
+                - `datetime`, `date` and `timestamp` are not type conversions: 422
+                  "Invalid operation: <name>."
+                - `number` reads a missing or empty field as 0.
+
                 **Handlebars operands**
                 - An operand can also be a string holding exactly one Handlebars expression, such as
                   `"{{record.status}}"` or `"{{lowercase record.code}}"`, on either side of the
@@ -803,6 +835,12 @@ components:
                   with 422 "invalid datetime format".
                 - A string with text around the expression, or with more than one expression, is
                   compared as a literal.
+                - `["number", "{{timestamp \"x\"}}"]` is the current time in epoch milliseconds,
+                  so `["greaterthanequals", ["epochtime", ["extract", "created"]], ["subtract",
+                  ["number", "{{timestamp \"x\"}}"], 604800000]]` keeps records created in the
+                  last 7 days.
+                - An unknown helper fails the rule with 422 "Failed to evaluate handlebars
+                  expression".
 
                 Choose the type conversion that matches the comparison — `number` for numeric
                 comparisons, `epochtime` for dates, `string` for text. For example:

package/dist/import.yml

@@ -12091,6 +12091,10 @@ components:
         - Items that don't match are completely skipped
         - No partial processing is performed
 
+        Send the whole object. A rules array sent alone as the `filter` value is not
+        stored, and a full update of an export that carries one removes the filter the
+        export had, with no error.
+
         **Implementation approaches**
 
         There are two distinct filtering mechanisms available:
@@ -12241,6 +12245,8 @@ components:
                 **Using `extract` to access record fields:**
                 - Retrieves values from the current record being processed
                 - Can access nested properties using dot notation (e.g., `"customer.email"`)
+                - Paths are relative to the record itself: `["extract", "record.status"]`
+                  matches nothing
                 - In a record filter, must be wrapped in a type conversion (`string`, `number`,
                   `boolean` or `epochtime`): a bare `["extract", ...]` operand is refused with 422
                   "Field operation extract must be called by a Type Conversion Operation but was called
@@ -12251,9 +12257,17 @@ components:
                 - Retrieves values from the integration's configuration settings
                 - Supports different scopes with prefix notation:
                   - `flow.settingName`: Access flow-level settings
-                  - `export.settingName`: Access export-level settings
-                  - `import.settingName`: Access import-level settings
+                  - `flowGrouping.settingName`: Access the flow group's settings
+                  - `export.settingName`: Access the export's (or lookup's) own settings
+                  - `import.settingName`: Access the import's own settings
                   - `integration.settingName`: Access integration-level settings
+                  - `connection.settingName`, `iClient.settingName`: Access the step's
+                    connection and iClient settings
+                - A scope whose resource has no settings can be absent; a rule that reads
+                  it matches nothing
+                - Must be wrapped in a type conversion like `extract`: a bare
+                  `["settings", ...]` operand is refused with 422 "Field operation settings
+                  must be called by a Type Conversion Operation"
                 - Useful for dynamic filtering based on configuration
 
                 **Field Transformations**
@@ -12263,6 +12277,24 @@ components:
                 - `"floor"`: Round number down to the nearest integer
                 - `"abs"`: Get absolute value of a number
 
+                **Arithmetic** (number operands)
+                - `"add"`, `"subtract"`, `"multiply"`, `"divide"`, `"modulo"`: for example
+                  `["subtract", ["number", ["extract", "total"]], ["number", ["extract", "discount"]]]`.
+                  `mod` is not an operator (422 "Invalid operation: mod.").
+
+                **Dates**
+                - `epochtime` reads ISO 8601 strings and epoch-millisecond numbers. An empty
+                  string, a string that isn't a date, or epoch milliseconds sent as a string
+                  fail it with "Invalid date. Cannot convert given string or number to date
+                  time.", followed by `; record=` and the record as JSON: in a run that record fails (`FILTER_EVALUATION_FAILED`, source
+                  `output_filter` on an export), and `POST /v1/processors/filter` and an
+                  export preview refuse the whole call with 422. `and` and `or` evaluate
+                  every operand, so a `notempty` test beside it doesn't prevent the failure.
+                  A missing or null field doesn't match.
+                - `datetime`, `date` and `timestamp` are not type conversions: 422
+                  "Invalid operation: <name>."
+                - `number` reads a missing or empty field as 0.
+
                 **Handlebars operands**
                 - An operand can also be a string holding exactly one Handlebars expression, such as
                   `"{{record.status}}"` or `"{{lowercase record.code}}"`, on either side of the
@@ -12274,6 +12306,12 @@ components:
                   with 422 "invalid datetime format".
                 - A string with text around the expression, or with more than one expression, is
                   compared as a literal.
+                - `["number", "{{timestamp \"x\"}}"]` is the current time in epoch milliseconds,
+                  so `["greaterthanequals", ["epochtime", ["extract", "created"]], ["subtract",
+                  ["number", "{{timestamp \"x\"}}"], 604800000]]` keeps records created in the
+                  last 7 days.
+                - An unknown helper fails the rule with 422 "Failed to evaluate handlebars
+                  expression".
 
                 Choose the type conversion that matches the comparison — `number` for numeric
                 comparisons, `epochtime` for dates, `string` for text. For example:

package/dist/lookupcache.yml

@@ -335,6 +335,11 @@ paths:
         Soft-deletes a lookup cache and all its data. Retained for 30 days
         before permanent removal. To clear data without deleting the cache
         itself, use `DELETE /v1/lookupcaches/{_id}/data/purge` instead.
+
+        A cache that an export's or import's lookup still uses, or that an
+        integration's alias points at, can't be deleted (422). The delete also
+        removes the cache from every integration's `_registeredLookupCacheIds`,
+        and restoring it from the recycle bin doesn't register it again.
       operationId: deleteLookupCache
       tags:
         - Lookup Caches
@@ -358,13 +363,26 @@ paths:
           $ref: '#/components/responses/404-not-found'
         '422':
           description: |-
-            An integration's `aliases[]` still points at the cache. Registering a cache adds such an
-            alias, so remove it from that integration's `aliases`, then delete again.
+            The cache is still in use. An integration's `aliases[]` points at it (checked first):
+            registering a cache adds such an alias, so remove it from that integration's `aliases`.
+            Or an export's or import's lookup uses it: the message names each such export or import
+            ("must be deleted before you can delete lookupcache"), and for an export in a flow names
+            that flow as well, but removing the lookup from the step is enough. Then delete again.
           content:
             application/json:
               schema:
                 $ref: '#/components/schemas/Error'
               examples:
+                export_referenced:
+                  summary: An export in a flow uses the cache in a Transformation 2.0 lookup
+                  value:
+                    errors:
+                      - message: export <exportId> must be deleted before you can delete lookupcache <lookupCacheId>; flow <flowId> must be deleted before you can delete lookupcache <lookupCacheId>
+                import_referenced:
+                  summary: An import in no flow uses the cache in an http.lookups entry
+                  value:
+                    errors:
+                      - message: import <importId> must be deleted before you can delete lookupcache <lookupCacheId>
                 alias_referenced:
                   value:
                     errors:

package/dist/processor.yml

@@ -1151,7 +1151,11 @@ paths:
           description: |-
             The rules are invalid, for example an unknown operator ("Invalid operation: isnotempty.") or
             an `extract` that is not wrapped in a type conversion ("Field operation extract must be called
-            by a Type Conversion Operation but was called by notempty.").
+            by a Type Conversion Operation but was called by notempty."). A valid rule is refused the same
+            way when a record holds a value its type conversion can't read: an `epochtime` operand on an
+            empty string, a string that isn't a date, or epoch milliseconds sent as a string fails the
+            whole call with "Invalid date. Cannot convert given string or number to date time.",
+            followed by `; record=` and that record as JSON.
           content:
             application/json:
               schema:

package/dist/tool.yml

@@ -23599,6 +23599,10 @@ components:
         - Items that don't match are completely skipped
         - No partial processing is performed
 
+        Send the whole object. A rules array sent alone as the `filter` value is not
+        stored, and a full update of an export that carries one removes the filter the
+        export had, with no error.
+
         **Implementation approaches**
 
         There are two distinct filtering mechanisms available:
@@ -23749,6 +23753,8 @@ components:
                 **Using `extract` to access record fields:**
                 - Retrieves values from the current record being processed
                 - Can access nested properties using dot notation (e.g., `"customer.email"`)
+                - Paths are relative to the record itself: `["extract", "record.status"]`
+                  matches nothing
                 - In a record filter, must be wrapped in a type conversion (`string`, `number`,
                   `boolean` or `epochtime`): a bare `["extract", ...]` operand is refused with 422
                   "Field operation extract must be called by a Type Conversion Operation but was called
@@ -23759,9 +23765,17 @@ components:
                 - Retrieves values from the integration's configuration settings
                 - Supports different scopes with prefix notation:
                   - `flow.settingName`: Access flow-level settings
-                  - `export.settingName`: Access export-level settings
-                  - `import.settingName`: Access import-level settings
+                  - `flowGrouping.settingName`: Access the flow group's settings
+                  - `export.settingName`: Access the export's (or lookup's) own settings
+                  - `import.settingName`: Access the import's own settings
                   - `integration.settingName`: Access integration-level settings
+                  - `connection.settingName`, `iClient.settingName`: Access the step's
+                    connection and iClient settings
+                - A scope whose resource has no settings can be absent; a rule that reads
+                  it matches nothing
+                - Must be wrapped in a type conversion like `extract`: a bare
+                  `["settings", ...]` operand is refused with 422 "Field operation settings
+                  must be called by a Type Conversion Operation"
                 - Useful for dynamic filtering based on configuration
 
                 **Field Transformations**
@@ -23771,6 +23785,24 @@ components:
                 - `"floor"`: Round number down to the nearest integer
                 - `"abs"`: Get absolute value of a number
 
+                **Arithmetic** (number operands)
+                - `"add"`, `"subtract"`, `"multiply"`, `"divide"`, `"modulo"`: for example
+                  `["subtract", ["number", ["extract", "total"]], ["number", ["extract", "discount"]]]`.
+                  `mod` is not an operator (422 "Invalid operation: mod.").
+
+                **Dates**
+                - `epochtime` reads ISO 8601 strings and epoch-millisecond numbers. An empty
+                  string, a string that isn't a date, or epoch milliseconds sent as a string
+                  fail it with "Invalid date. Cannot convert given string or number to date
+                  time.", followed by `; record=` and the record as JSON: in a run that record fails (`FILTER_EVALUATION_FAILED`, source
+                  `output_filter` on an export), and `POST /v1/processors/filter` and an
+                  export preview refuse the whole call with 422. `and` and `or` evaluate
+                  every operand, so a `notempty` test beside it doesn't prevent the failure.
+                  A missing or null field doesn't match.
+                - `datetime`, `date` and `timestamp` are not type conversions: 422
+                  "Invalid operation: <name>."
+                - `number` reads a missing or empty field as 0.
+
                 **Handlebars operands**
                 - An operand can also be a string holding exactly one Handlebars expression, such as
                   `"{{record.status}}"` or `"{{lowercase record.code}}"`, on either side of the
@@ -23782,6 +23814,12 @@ components:
                   with 422 "invalid datetime format".
                 - A string with text around the expression, or with more than one expression, is
                   compared as a literal.
+                - `["number", "{{timestamp \"x\"}}"]` is the current time in epoch milliseconds,
+                  so `["greaterthanequals", ["epochtime", ["extract", "created"]], ["subtract",
+                  ["number", "{{timestamp \"x\"}}"], 604800000]]` keeps records created in the
+                  last 7 days.
+                - An unknown helper fails the rule with 422 "Failed to evaluate handlebars
+                  expression".
 
                 Choose the type conversion that matches the comparison — `number` for numeric
                 comparisons, `epochtime` for dates, `string` for text. For example:

package/dist/tradingpartnerconnector.yml

@@ -488,6 +488,10 @@ components:
         - Items that don't match are completely skipped
         - No partial processing is performed
 
+        Send the whole object. A rules array sent alone as the `filter` value is not
+        stored, and a full update of an export that carries one removes the filter the
+        export had, with no error.
+
         **Implementation approaches**
 
         There are two distinct filtering mechanisms available:
@@ -638,6 +642,8 @@ components:
                 **Using `extract` to access record fields:**
                 - Retrieves values from the current record being processed
                 - Can access nested properties using dot notation (e.g., `"customer.email"`)
+                - Paths are relative to the record itself: `["extract", "record.status"]`
+                  matches nothing
                 - In a record filter, must be wrapped in a type conversion (`string`, `number`,
                   `boolean` or `epochtime`): a bare `["extract", ...]` operand is refused with 422
                   "Field operation extract must be called by a Type Conversion Operation but was called
@@ -648,9 +654,17 @@ components:
                 - Retrieves values from the integration's configuration settings
                 - Supports different scopes with prefix notation:
                   - `flow.settingName`: Access flow-level settings
-                  - `export.settingName`: Access export-level settings
-                  - `import.settingName`: Access import-level settings
+                  - `flowGrouping.settingName`: Access the flow group's settings
+                  - `export.settingName`: Access the export's (or lookup's) own settings
+                  - `import.settingName`: Access the import's own settings
                   - `integration.settingName`: Access integration-level settings
+                  - `connection.settingName`, `iClient.settingName`: Access the step's
+                    connection and iClient settings
+                - A scope whose resource has no settings can be absent; a rule that reads
+                  it matches nothing
+                - Must be wrapped in a type conversion like `extract`: a bare
+                  `["settings", ...]` operand is refused with 422 "Field operation settings
+                  must be called by a Type Conversion Operation"
                 - Useful for dynamic filtering based on configuration
 
                 **Field Transformations**
@@ -660,6 +674,24 @@ components:
                 - `"floor"`: Round number down to the nearest integer
                 - `"abs"`: Get absolute value of a number
 
+                **Arithmetic** (number operands)
+                - `"add"`, `"subtract"`, `"multiply"`, `"divide"`, `"modulo"`: for example
+                  `["subtract", ["number", ["extract", "total"]], ["number", ["extract", "discount"]]]`.
+                  `mod` is not an operator (422 "Invalid operation: mod.").
+
+                **Dates**
+                - `epochtime` reads ISO 8601 strings and epoch-millisecond numbers. An empty
+                  string, a string that isn't a date, or epoch milliseconds sent as a string
+                  fail it with "Invalid date. Cannot convert given string or number to date
+                  time.", followed by `; record=` and the record as JSON: in a run that record fails (`FILTER_EVALUATION_FAILED`, source
+                  `output_filter` on an export), and `POST /v1/processors/filter` and an
+                  export preview refuse the whole call with 422. `and` and `or` evaluate
+                  every operand, so a `notempty` test beside it doesn't prevent the failure.
+                  A missing or null field doesn't match.
+                - `datetime`, `date` and `timestamp` are not type conversions: 422
+                  "Invalid operation: <name>."
+                - `number` reads a missing or empty field as 0.
+
                 **Handlebars operands**
                 - An operand can also be a string holding exactly one Handlebars expression, such as
                   `"{{record.status}}"` or `"{{lowercase record.code}}"`, on either side of the
@@ -671,6 +703,12 @@ components:
                   with 422 "invalid datetime format".
                 - A string with text around the expression, or with more than one expression, is
                   compared as a literal.
+                - `["number", "{{timestamp \"x\"}}"]` is the current time in epoch milliseconds,
+                  so `["greaterthanequals", ["epochtime", ["extract", "created"]], ["subtract",
+                  ["number", "{{timestamp \"x\"}}"], 604800000]]` keeps records created in the
+                  last 7 days.
+                - An unknown helper fails the rule with 422 "Failed to evaluate handlebars
+                  expression".
 
                 Choose the type conversion that matches the comparison — `number` for numeric
                 comparisons, `epochtime` for dates, `string` for text. For example:

package/package.json

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

package/schemas.json

@@ -1,8 +1,8 @@
 {
 	"provenance": {
 		"repo": "celigo/integrator-api-specs",
-		"iasCommit": "d6523356",
-		"generatedAt": "2026-10-21"
+		"iasCommit": "2df59293",
+		"generatedAt": "2026-10-22"
 	},
 	"roots": {
 		"aiagent": 134,