@celigo/api-specs 0.2.214 → 0.2.215

package/dist/flow.yml

@@ -2153,12 +2153,14 @@ paths:
 
         The `data` field is the record as the failing stage held it: for an import-stage error
         (`page_processor_import`) on an HTTP import, the record before the import's mappings, not the
-        request the import sent; for a postResponseMap hook's error (`post_response_mapping`), the record
+        request the import sent; for a lookup's error (`page_processor_export`), the record as it reached
+        the lookup; for a postResponseMap hook's error (`post_response_mapping`), the record
         after the step's response mapping. Use `PUT .../{retryDataKey}/data` to mutate
         the snapshot before retrying. Only errors with a `retryDataKey` expose this endpoint;
         connection-class errors are rejected with `no_retrydata_found`. The `stage` field indicates
         where the retry will resume: `page_processor_import` re-runs the import (most common, and where a
-        postSubmit hook's errors are stored, so their retry writes the records again),
+        postSubmit hook's errors are stored — a retry writes again a record the destination accepted,
+        and resends one whose refusal the hook reworded), `page_processor_export` re-runs the lookup,
         `post_response_mapping` (a postResponseMap hook's error) resumes after the import from the stored
         reply in `adaptorResponse`, sending nothing to the destination again and carrying the record on
         to the flow's next steps, and `page_generator` means the error was upstream of the processor.
@@ -4342,6 +4344,10 @@ paths:
 
         An empty object `{}` means no other resources depend on the target — this is also returned for a
         well-formatted but nonexistent id.
+
+        A `flows` entry whose `paths` holds `_runNextFlowIds` is an upstream flow: its own
+        `_runNextFlowIds` lists this flow, so this flow starts when a run of that one completes. The
+        flows this flow starts are in its own `_runNextFlowIds`, not in this response.
       parameters:
         - name: _id
           in: path
@@ -4364,7 +4370,7 @@ paths:
                   summary: No dependents (also returned for a nonexistent id)
                   value: {}
                 populated:
-                  summary: Another flow is configured to run after this one
+                  summary: Another flow starts this one when its run completes
                   value:
                     flows:
                       - id: 69f4b2cb95ec28be9ca1a88d
@@ -5847,9 +5853,11 @@ components:
             - string
             - 'null'
           description: |-
-            IANA timezone for the schedule (e.g. `America/New_York`). Defaults to UTC. The flow's
-            `schedule` and each page generator's own `schedule` are read in this timezone; a page
-            generator has no timezone of its own.
+            IANA timezone for the schedule (e.g. `America/New_York`). The flow's `schedule` and each
+            page generator's own `schedule` are read in this timezone; a page generator has no
+            timezone of its own. A flow saved without one stores none, and its schedule then runs in
+            UTC when the account owner's profile has no time zone; per the Help Center's time zone
+            precedence, it runs in the owner's profile time zone when the profile sets one.
           examples:
             - America/New_York
             - Europe/London
@@ -6935,8 +6943,10 @@ components:
             `application` covers the step's whole call to the external system, not only its answer:
             besides errors the destination returned, it marks a request that never got an answer,
             such as a URL template that failed to render (`handlebars_template_parse_error`) or a
-            refused connection, so read `code` and `message` with it. `GET /v1/errors/filterMetadata`
-            lists the source values the errors filter accepts.
+            refused connection, so read `code` and `message` with it. `post_submit_hook` marks an error
+            a postSubmit hook added or reworded — a destination refusal included — while one the hook
+            passes along unchanged keeps `application`, so it does not mean the destination accepted the
+            record. `GET /v1/errors/filterMetadata` lists the source values the errors filter accepts.
           examples:
             - application
         code:
@@ -7831,7 +7841,8 @@ components:
             (an import's errors, a postSubmit hook's included) it is the incoming record, before the
             import's mappings — not the request body the import sent or the response it got back — and a
             retry maps it again with the import's current mappings, so a mapping fix reaches the retried
-            record. At `post_response_mapping` (a postResponseMap hook's error) it is the record after the
+            record. At `page_processor_export` (a lookup's errors) it is the record as it reached the
+            lookup. At `post_response_mapping` (a postResponseMap hook's error) it is the record after the
             step's response mapping, with the mapped fields: a retry neither maps nor sends it again, and
             the destination's reply is in `adaptorResponse`. Shape varies by adaptor.
           additionalProperties: true
@@ -7840,14 +7851,25 @@ components:
           description: |-
             Pipeline stage where the record was when the error occurred, which is where a retry resumes.
             `page_processor_import` is the record as it entered the import, so a retry sends it to the
-            destination again; a postSubmit hook's errors are stored here, so retrying them writes records
-            the destination already accepted a second time (live, 2026-10-22). `post_response_mapping` is a
-            postResponseMap hook's error, raised after the destination answered: a retry runs the hook from
-            the stored reply and carries the record on to the flow's next steps, sending nothing to that
-            destination again (live, 2026-10-23 and 2026-10-25: the import's request count didn't change,
-            and the next import received the retried records).
+            destination again. A postSubmit hook's errors are stored here whether the destination accepted
+            the record or refused it and the hook reworded the refusal (live, 2026-10-30), so neither the
+            stage nor the error's `post_submit_hook` source says whether the record was written: retrying
+            an error the hook raised after the destination accepted the record writes it a second time
+            (live, 2026-10-22), while a reworded refusal is a record the destination did not take.
+            `page_processor_export` is a lookup's error: a retry runs the lookup again as it is configured
+            now (live, 2026-10-30: after the lookup's template was fixed, the retried records succeeded).
+            `post_response_mapping` is a postResponseMap hook's error, raised after the destination
+            answered: a retry runs the hook from the stored reply and carries the record on to the flow's
+            next steps, sending nothing to that destination again (live, 2026-10-23 and 2026-10-25: the
+            import's request count didn't change, and the next import received the retried records).
+          x-celigo-ai-guidance:
+            - |-
+              Before retrying `post_submit_hook` errors, find out whether the destination took each
+              record — the hook's message, or a lookup of the record in the destination — and retry the
+              refusals. A hook error on a record the destination accepted is written again by the retry.
           examples:
             - page_processor_import
+            - page_processor_export
             - post_response_mapping
             - importMappingExtract
         pgExportId:

package/dist/import.yml

@@ -15442,12 +15442,16 @@ components:
                     - |-
                       On a grouped record (the export groups rows, so the record is an
                       array) only `create` can author output — build it from the rows with
-                      `$[0].field`, `$[*].field`, or a `buildArrayHelper` over `$[*]`.
+                      `$[0].field`, `$[*].field`, or a `buildArrayHelper` over `$[*]`
+                      (`$.rows[0].field` and `$.rows[*]` with `inputContext: envelope`).
                       `modify` has no object to overlay onto an array: the record passes
-                      through untouched and the processor reports success. Either mode
-                      reshapes the inside of one record; neither changes how many records
-                      the page carries (that is the export's `preSavePage` hook) or whether
-                      the export groups at all (that is its grouping setting).
+                      through untouched and the processor reports success. Paths written
+                      for one object record (`$.field`, an entry `$.lines[*]`) resolve
+                      nothing there, so `create` returns `{}` for each record, also with
+                      no error (live, 2026-10-30). Either mode reshapes the inside of one
+                      record; neither changes how many records the page carries (that is
+                      the export's `preSavePage` hook) or whether the export groups at all
+                      (that is its grouping setting).
                   examples:
                     - create
                     - modify
@@ -15512,8 +15516,8 @@ components:
                     - record
                     - envelope
                   x-enumDescriptions:
-                    record: The transform processor evaluates `mappings[].extract` JSONPath against the flat record itself (`$.field`, no `record.` segment) — the default when absent.
-                    envelope: The transform processor evaluates JSONPath against the wrapped runtime envelope `{record, job, testMode, settings, headers, queryParams}` (file-provider steps also carry `fileMeta`) — record fields need the `record.` segment (`$.record.field`), while `headers` and `queryParams` sit beside `record` (`$.headers['X-Id']`, `$.queryParams.src`).
+                    record: The transform processor evaluates `mappings[].extract` JSONPath against the flat record itself (`$.field`, no `record.` segment; a grouped record is the array of rows, `$[0].field`) — the default when absent.
+                    envelope: The transform processor evaluates JSONPath against the wrapped runtime envelope `{record, job, testMode, settings, headers, queryParams}` (file-provider steps also carry `fileMeta`) — record fields need the `record.` segment (`$.record.field`), and a grouped record sits under `rows` instead (`$.rows[0].field`), while `headers` and `queryParams` sit beside `record` (`$.headers['X-Id']`, `$.queryParams.src`).
                   description: |
                     Controls the JSON shape the transformTwoDotZero processor
                     evaluates `mappings[].extract` JSONPath values against at
@@ -15529,24 +15533,38 @@ components:
                         processor sees the FLAT record as its evaluation root.
                         `mappings[].extract` JSONPath MUST anchor directly at
                         `$` with NO `record.` segment — e.g. `"$.orderId"`,
-                        `"$.customer.email"`; PLACEHOLDER extracts use
+                        `"$.customer.email"` on an object record, `"$[0].orderId"`
+                        on a grouped one; PLACEHOLDER extracts use
                         `"$.PLACEHOLDER_<field>"`.
                         This is the dominant Celigo idiom and the right choice for new transforms.
                       - `envelope`: the processor sees a wrapped object
                         `{record: {...}, job, testMode, settings, headers,
                         queryParams}` (plus `fileMeta` on file-provider steps).
                         `mappings[].extract` JSONPath MUST include the
-                        `record.` segment for record fields — e.g.
-                        `"$.record.orderId"` — and reads `headers` and
+                        `record.` segment for an object record's fields — e.g.
+                        `"$.record.orderId"`; a grouped record sits under `rows`
+                        instead (`"$.rows[0].orderId"`) — and reads `headers` and
                         `queryParams` beside it (`$.headers['X-Id']`);
                         PLACEHOLDER extracts use `"$.record.PLACEHOLDER_<field>"`.
                         Pick this only when the transform was authored against
                         the envelope shape on purpose.
                     - |-
-                      Handlebars expressions inside `extract`
-                      (`{{record.field}}`, `{{dateFormat ... record.field}}`)
-                      ALWAYS reference the `record` root regardless of
+                      Handlebars expressions inside `extract` reference the
+                      `record` root on an object record (`{{record.field}}`,
+                      `{{dateFormat ... record.field}}`) and `rows` on a
+                      grouped one (`{{rows.0.field}}`), regardless of
                       `inputContext` — only JSONPath anchoring flips.
+                    - |-
+                      ## Grouped records
+
+                      When the export groups rows, each record is an array of
+                      rows. In `record` mode JSONPath roots at that array
+                      (`$[0].field`, `$[*]`); `envelope` binds it as `rows`,
+                      not `record` — `$.rows[0].field`, and an entry
+                      `$.rows[*]` whose children read `$.rows.field` — while
+                      `$.record[0].field` and `$.record[*]` resolve nothing,
+                      with no error (live, 2026-10-30). Handlebars extracts
+                      read it as `rows` in both modes (`{{rows.0.field}}`).
                     - |-
                       In `envelope` mode the output is still a bare record: a
                       `modify` transform returns the record with its mapped
@@ -15567,7 +15585,8 @@ components:
                         ``mappings[].extract`` JSONPath values MUST anchor
                         directly at ``$`` with NO ``record.`` segment — for
                         example ``"$.orderId"`` or
-                        ``"$.customer.email"``.  PLACEHOLDER extracts use
+                        ``"$.customer.email"`` on an object record, and
+                        ``"$[0].orderId"`` on a grouped one.  PLACEHOLDER extracts use
                         ``"$.PLACEHOLDER_<field>"``.  This is the dominant
                         Celigo idiom and the right choice for new transforms.
 
@@ -15579,9 +15598,10 @@ components:
                         ``record``) — the
                         same runtime-context envelope Handlebars / SQL /
                         GraphQL templates render against.  ``mappings[].extract``
-                        JSONPath values for record fields MUST include the
+                        JSONPath values for an object record's fields MUST include the
                         ``record.`` segment — for example ``"$.record.orderId"``
-                        or ``"$.record.customer.email"`` — while ``headers`` and
+                        or ``"$.record.customer.email"``; a grouped record's rows
+                        sit under ``rows`` instead (``"$.rows[0].orderId"``) — while ``headers`` and
                         ``queryParams`` are read beside it
                         (``"$.headers['X-Id']"``).  PLACEHOLDER extracts
                         use ``"$.record.PLACEHOLDER_<field>"``.  Pick this
@@ -15594,8 +15614,9 @@ components:
 
                       Handlebars expressions inside ``extract``
                       (``{{record.field}}``,
-                      ``{{dateFormat ... record.field}}``, etc.) ALWAYS
-                      reference the runtime context's ``record`` root
+                      ``{{dateFormat ... record.field}}``, etc.) reference the
+                      runtime context's ``record`` root on an object record,
+                      and ``rows`` (``{{rows.0.field}}``) on a grouped one,
                       regardless of ``inputContext`` — the Handlebars runtime
                       always sees the wrapped envelope.  Only JSONPath
                       behavior flips with this field.

package/dist/processor.yml

@@ -1179,8 +1179,10 @@ paths:
         `http.relativeURI`; triple braces insert it unchanged. A `timestamp` with no time zone
         renders in UTC.
 
-        A null value, or a field under an object that is null, renders empty here. An HTTP import
-        escapes values its own way, at run time and in the import preview: in its JSON body a
+        By default a null value, a field under an object that is null, and a path the data doesn't
+        carry all render empty here. With `rules.strict` true, a path the data doesn't carry or one
+        through a null object fails with 422, while a null or empty value still renders empty. An
+        HTTP import escapes values its own way, at run time and in the import preview: in its JSON body a
         double-brace value that is null, or under a null object, is written as the text `null`
         (triple braces rendered `{{{record.customer.name}}}` empty, whether `customer` or its `name`
         was null); in its relative URI a null field is sent as the text
@@ -1221,6 +1223,21 @@ paths:
                       description: Form of the result; `text` returns the rendered string.
                       examples:
                         - text
+                    strict:
+                      type: boolean
+                      default: false
+                      description: |-
+                        When true, a path the data doesn't carry, or one through a missing or null
+                        object, fails the render with 422 instead of rendering empty: `"poNumber" not
+                        defined in the model`, or `not defined in undefined` / `not defined in null`
+                        when the object above it is missing or null — the detail a step's
+                        `handlebars_template_parse_error` carries. A null or empty value still renders
+                        empty.
+                      x-celigo-ai-guidance:
+                        - |-
+                          Render with `strict: true` to check a template's paths against a sample
+                          record: by default a misspelled or wrongly rooted path (`{{record.poNumber}}`
+                          on a record that carries `po_number`) renders empty with 200.
                 options:
                   type: object
                   description: |-
@@ -1292,6 +1309,16 @@ paths:
                   data:
                     record:
                       name: Smith & Sons
+              strict:
+                summary: Fail on a path the record doesn't carry
+                value:
+                  rules:
+                    template: '{{record.poNumber}}'
+                    resultMode: text
+                    strict: true
+                  data:
+                    record:
+                      po_number: '10482'
               static_lookup:
                 summary: Resolve an HTTP import's static lookup
                 value:
@@ -1352,7 +1379,8 @@ paths:
         '422':
           description: |-
             The template could not be rendered, for example because it calls a helper that does not
-            exist ('Missing helper: "first"').
+            exist ('Missing helper: "first"') or, with `rules.strict`, reads a path the data doesn't
+            carry ('"poNumber" not defined in the model').
           content:
             application/json:
               schema:

package/dist/subscription.yml

@@ -518,7 +518,8 @@ components:
           description: |-
             Base number of endpoints (distinct connected applications) included with the plan, per
             environment. Whether the count is taken from endpoints in use or from endpoints invoked
-            in the billing period depends on the account's pricing model.
+            in the billing period depends on the account's pricing model, which the license's `type`
+            names.
           example: 600
         numAddOnEndpoints:
           type: integer
@@ -529,7 +530,7 @@ components:
           description: |-
             Base flow entitlement included with the plan, per environment. Whether it caps enabled
             flows or the distinct flows run in a billing period — and whether reaching it blocks or
-            only notifies — depends on the account's pricing model.
+            only notifies — depends on the account's pricing model, which the license's `type` names.
           example: 80
         numAddOnFlows:
           type: integer
@@ -581,9 +582,14 @@ components:
           the number of environments, prepaid AI balances, and the other non-resource fields —
           belong to the parent license and are not repeated per environment.
         - |-
-          What a flow or endpoint entitlement METERS depends on the account's pricing model
-          (`type` plus tier generation). Interpret the counts for the plan this account is on
-          only; do not infer the rule from field names.
+          No field names what a flow or endpoint entitlement METERS; the account-level license's
+          `type` tells it. A `platform` license meters runs: on `GET /v1/licenseEntitlementUsage`,
+          `flowUsage.numEnabled` counts the distinct flows that ran in the billing period and
+          `endpointUsage.numConsumed` the endpoints they used, and `GET /v1/historicalMonthlyUsage`
+          returns its monthly rows. An `endpoint` license meters enabled resources: its endpoints are
+          counted across enabled flows. Neither `endpoint` nor `integrator` licenses store monthly
+          usage (that route fails with 500 for them). Interpret the counts for the plan this account
+          is on only; do not infer the rule from field names such as `numEnabled`.
       properties:
         _id:
           type: string
@@ -632,8 +638,8 @@ components:
             - integrationAppChild
           x-enumDescriptions:
             integrator: Account-level subscription (legacy integrator pricing model).
-            platform: Account-level subscription (platform pricing model; the tier name carries the plan generation).
-            endpoint: Account-level subscription (endpoint pricing model, metered on distinct endpoints).
+            platform: Account-level subscription (platform pricing model, metered on flow runs in the billing period; the tier name carries the plan generation).
+            endpoint: Account-level subscription (endpoint pricing model, metered on the distinct endpoints enabled flows use).
             connector: Connector-specific license for an Integration App.
             integrationApp: Integration App license (parent).
             integrationAppChild: Integration App child license (inherits from a parent via `_parentId`).

package/dist/tool.yml

@@ -6276,12 +6276,16 @@ components:
                     - |-
                       On a grouped record (the export groups rows, so the record is an
                       array) only `create` can author output — build it from the rows with
-                      `$[0].field`, `$[*].field`, or a `buildArrayHelper` over `$[*]`.
+                      `$[0].field`, `$[*].field`, or a `buildArrayHelper` over `$[*]`
+                      (`$.rows[0].field` and `$.rows[*]` with `inputContext: envelope`).
                       `modify` has no object to overlay onto an array: the record passes
-                      through untouched and the processor reports success. Either mode
-                      reshapes the inside of one record; neither changes how many records
-                      the page carries (that is the export's `preSavePage` hook) or whether
-                      the export groups at all (that is its grouping setting).
+                      through untouched and the processor reports success. Paths written
+                      for one object record (`$.field`, an entry `$.lines[*]`) resolve
+                      nothing there, so `create` returns `{}` for each record, also with
+                      no error (live, 2026-10-30). Either mode reshapes the inside of one
+                      record; neither changes how many records the page carries (that is
+                      the export's `preSavePage` hook) or whether the export groups at all
+                      (that is its grouping setting).
                   examples:
                     - create
                     - modify
@@ -6346,8 +6350,8 @@ components:
                     - record
                     - envelope
                   x-enumDescriptions:
-                    record: The transform processor evaluates `mappings[].extract` JSONPath against the flat record itself (`$.field`, no `record.` segment) — the default when absent.
-                    envelope: The transform processor evaluates JSONPath against the wrapped runtime envelope `{record, job, testMode, settings, headers, queryParams}` (file-provider steps also carry `fileMeta`) — record fields need the `record.` segment (`$.record.field`), while `headers` and `queryParams` sit beside `record` (`$.headers['X-Id']`, `$.queryParams.src`).
+                    record: The transform processor evaluates `mappings[].extract` JSONPath against the flat record itself (`$.field`, no `record.` segment; a grouped record is the array of rows, `$[0].field`) — the default when absent.
+                    envelope: The transform processor evaluates JSONPath against the wrapped runtime envelope `{record, job, testMode, settings, headers, queryParams}` (file-provider steps also carry `fileMeta`) — record fields need the `record.` segment (`$.record.field`), and a grouped record sits under `rows` instead (`$.rows[0].field`), while `headers` and `queryParams` sit beside `record` (`$.headers['X-Id']`, `$.queryParams.src`).
                   description: |
                     Controls the JSON shape the transformTwoDotZero processor
                     evaluates `mappings[].extract` JSONPath values against at
@@ -6363,24 +6367,38 @@ components:
                         processor sees the FLAT record as its evaluation root.
                         `mappings[].extract` JSONPath MUST anchor directly at
                         `$` with NO `record.` segment — e.g. `"$.orderId"`,
-                        `"$.customer.email"`; PLACEHOLDER extracts use
+                        `"$.customer.email"` on an object record, `"$[0].orderId"`
+                        on a grouped one; PLACEHOLDER extracts use
                         `"$.PLACEHOLDER_<field>"`.
                         This is the dominant Celigo idiom and the right choice for new transforms.
                       - `envelope`: the processor sees a wrapped object
                         `{record: {...}, job, testMode, settings, headers,
                         queryParams}` (plus `fileMeta` on file-provider steps).
                         `mappings[].extract` JSONPath MUST include the
-                        `record.` segment for record fields — e.g.
-                        `"$.record.orderId"` — and reads `headers` and
+                        `record.` segment for an object record's fields — e.g.
+                        `"$.record.orderId"`; a grouped record sits under `rows`
+                        instead (`"$.rows[0].orderId"`) — and reads `headers` and
                         `queryParams` beside it (`$.headers['X-Id']`);
                         PLACEHOLDER extracts use `"$.record.PLACEHOLDER_<field>"`.
                         Pick this only when the transform was authored against
                         the envelope shape on purpose.
                     - |-
-                      Handlebars expressions inside `extract`
-                      (`{{record.field}}`, `{{dateFormat ... record.field}}`)
-                      ALWAYS reference the `record` root regardless of
+                      Handlebars expressions inside `extract` reference the
+                      `record` root on an object record (`{{record.field}}`,
+                      `{{dateFormat ... record.field}}`) and `rows` on a
+                      grouped one (`{{rows.0.field}}`), regardless of
                       `inputContext` — only JSONPath anchoring flips.
+                    - |-
+                      ## Grouped records
+
+                      When the export groups rows, each record is an array of
+                      rows. In `record` mode JSONPath roots at that array
+                      (`$[0].field`, `$[*]`); `envelope` binds it as `rows`,
+                      not `record` — `$.rows[0].field`, and an entry
+                      `$.rows[*]` whose children read `$.rows.field` — while
+                      `$.record[0].field` and `$.record[*]` resolve nothing,
+                      with no error (live, 2026-10-30). Handlebars extracts
+                      read it as `rows` in both modes (`{{rows.0.field}}`).
                     - |-
                       In `envelope` mode the output is still a bare record: a
                       `modify` transform returns the record with its mapped
@@ -6401,7 +6419,8 @@ components:
                         ``mappings[].extract`` JSONPath values MUST anchor
                         directly at ``$`` with NO ``record.`` segment — for
                         example ``"$.orderId"`` or
-                        ``"$.customer.email"``.  PLACEHOLDER extracts use
+                        ``"$.customer.email"`` on an object record, and
+                        ``"$[0].orderId"`` on a grouped one.  PLACEHOLDER extracts use
                         ``"$.PLACEHOLDER_<field>"``.  This is the dominant
                         Celigo idiom and the right choice for new transforms.
 
@@ -6413,9 +6432,10 @@ components:
                         ``record``) — the
                         same runtime-context envelope Handlebars / SQL /
                         GraphQL templates render against.  ``mappings[].extract``
-                        JSONPath values for record fields MUST include the
+                        JSONPath values for an object record's fields MUST include the
                         ``record.`` segment — for example ``"$.record.orderId"``
-                        or ``"$.record.customer.email"`` — while ``headers`` and
+                        or ``"$.record.customer.email"``; a grouped record's rows
+                        sit under ``rows`` instead (``"$.rows[0].orderId"``) — while ``headers`` and
                         ``queryParams`` are read beside it
                         (``"$.headers['X-Id']"``).  PLACEHOLDER extracts
                         use ``"$.record.PLACEHOLDER_<field>"``.  Pick this
@@ -6428,8 +6448,9 @@ components:
 
                       Handlebars expressions inside ``extract``
                       (``{{record.field}}``,
-                      ``{{dateFormat ... record.field}}``, etc.) ALWAYS
-                      reference the runtime context's ``record`` root
+                      ``{{dateFormat ... record.field}}``, etc.) reference the
+                      runtime context's ``record`` root on an object record,
+                      and ``rows`` (``{{rows.0.field}}``) on a grouped one,
                       regardless of ``inputContext`` — the Handlebars runtime
                       always sees the wrapped envelope.  Only JSONPath
                       behavior flips with this field.
@@ -38512,8 +38533,8 @@ components:
         **Structure**
 
         The mock output must follow the integrator.io canonical format, which consists of a
-        `page_of_records` array containing record objects. Each record object has a `record`
-        property that contains the actual data fields.
+        `page_of_records` array of items. On an export that does not group rows, each item has a
+        `record` property that contains the actual data fields:
 
         ```json
         {
@@ -38530,6 +38551,19 @@ components:
         }
         ```
 
+        An export that groups rows (`groupByFields`) produces records that are arrays of rows, and
+        each item then carries `rows` instead of `record`, holding the rows of one grouped record. A
+        flow test run saves a grouped export's records in this form:
+
+        ```json
+        {
+          "page_of_records": [
+            { "rows": [ { "field1": "value1" }, { "field1": "value2" } ] },
+            ...
+          ]
+        }
+        ```
+
         **Usage**
 
         In a flow test run, and for an upstream lookup during a page-processor preview
@@ -38562,7 +38596,8 @@ components:
 
         - Maximum of 10 records
         - Maximum size of 1 MB
-        - Must follow the canonical format shown above
+        - Must follow one of the canonical formats shown above: every item `{"record": {...}}`, or
+          on a grouped export every item `{"rows": [...]}`
 
         Mock output can be populated automatically from preview data (which is the parsed response,
         before `transform` / `filter`) or entered manually.
@@ -38604,6 +38639,22 @@ components:
                   categories:
                     - Electronics
                     - Accessories
+              rows:
+                type: array
+                description: |
+                  The rows of one grouped record, present instead of `record` when the export
+                  groups rows (`groupByFields`). Every item of a grouped export's mock carries
+                  `rows`.
+                items:
+                  type: object
+                  additionalProperties: true
+                example:
+                  - orderId: SO-1001
+                    sku: SKU-100
+                    quantity: 2
+                  - orderId: SO-1001
+                    sku: SKU-200
+                    quantity: 1
       example:
         page_of_records:
           - record:

package/package.json

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