@celigo/api-specs 0.2.190 → 0.2.191

package/dist/connection.yml

@@ -1879,7 +1879,12 @@ paths:
                             searchValue: SEED-01
       responses:
         '200':
-          description: The records the source returned, with a per-record link when the adaptor provides one.
+          description: |-
+            The records the source returned, with a per-record link when the adaptor provides one.
+            When paging stopped on a repeated page (observed 2026-10-23), the body was instead
+            `text/plain` holding two JSON objects in a row: the records read, then
+            `{"errors": [...]}` carrying the `page_response_error`. A client that parses that body as
+            one JSON document fails on it; split it into its objects.
           content:
             application/json:
               schema:
@@ -1912,6 +1917,16 @@ paths:
                         externalid: SEED-01
                     dataURIs:
                       - https://1234567.app.netsuite.com/app/common/custom/custrecordentry.nl?rectype=923&id=1
+            text/plain:
+              schema:
+                type: string
+                description: |-
+                  Observed only when paging stopped on a repeated page (2026-10-23): two JSON objects
+                  in a row, the records read and then the errors.
+              examples:
+                paging_stopped:
+                  summary: Paging stopped because a next page repeated the previous one
+                  value: '{"data":[{"id":"o-a"},{"id":"o-b"}],"dataURIs":[null,null]}{"errors":[{"code":"page_response_error","message":"Identical response received from next page request. No more page requests will be made.","source":"resource","resolved":false}]}'
         '400':
           description: The top-level `export` object is missing.
           content:

package/dist/export.yml

@@ -695,7 +695,10 @@ paths:
             (after its transform, output filter and preSavePage hook) or an
             `errors` array if the export encountered application-level failures
             (connection timeout, file not found, etc.). Always inspect for errors
-            even on 200.
+            even on 200. When paging stopped on a repeated page (observed 2026-10-23), the body
+            was instead `text/plain` holding two JSON objects in a row: the records read (`data`,
+            `dataURIs`), then `{"errors": [...]}` carrying the `page_response_error`. A client that
+            parses that body as one JSON document fails on it; split it into its objects.
           content:
             application/json:
               schema:
@@ -715,6 +718,16 @@ paths:
                           service: file-adaptor
                         resolved: false
                         occurredAt: 1777645522601
+            text/plain:
+              schema:
+                type: string
+                description: |-
+                  Observed only when paging stopped on a repeated page (2026-10-23): two JSON objects
+                  in a row, the records read and then the errors.
+              examples:
+                paging_stopped:
+                  summary: Paging stopped because a next page repeated the previous one
+                  value: '{"data":[{"id":"o-a"},{"id":"o-b"}],"dataURIs":[null,null]}{"errors":[{"code":"page_response_error","message":"Identical response received from next page request. No more page requests will be made.","source":"resource","resolved":false}]}'
         '401':
           $ref: '#/components/responses/401-unauthorized'
         '404':
@@ -6696,7 +6709,7 @@ components:
 
             When this export is the first lookup of a builder-mode API with `pagination.enabled` set, it is that API's volume driver: saving the export (even unchanged) invalidates the API's issued cursors, so a caller mid-walk gets an empty final page, and removing `paging` is accepted on save but makes every call to the API fail with `400 api_pagination_source_not_paged` until paging is restored or the API's flag is turned off.
 
-            When a next page's response is identical to the previous one, paging stops: the export records an open error with code `page_response_error` ("Identical response received from next page request. No more page requests will be made.") and the run completes with the pages already read, so later pages are never exported. A request that doesn't change between pages produces this, as observed with `method: page` and the pagination variable missing from the relative URI and body; reference the variable so each request asks for the next page.
+            When a next page's response is identical to the previous one, paging stops: the export records an open error with code `page_response_error` ("Identical response received from next page request. No more page requests will be made.") and later pages are never exported. A request that doesn't change between pages produces this, as observed with `method: page` and the pagination variable missing from the relative URI and body; reference the variable so each request asks for the next page. In that probe (an HTTP export, 2026-10-23) the run completed with the pages already read when the export had no `type`, and failed when it had `type: "delta"`: the steps after the export received nothing and the checkpoint didn't move. Other `type` values weren't tried. An invoke of that export, or a virtual export of the same document, answered 200 with the records read, then `{"errors": [...]}` carrying the `page_response_error`, as two JSON objects in one `text/plain` body.
           x-celigo-ai-guidance:
             - Configuration object for navigating through multi-page API responses.
             - |-

package/dist/flow.yml

@@ -904,7 +904,22 @@ paths:
         '401':
           $ref: '#/components/responses/401-unauthorized'
         '404':
-          $ref: '#/components/responses/404-not-found'
+          description: |-
+            Flow not found ("Flow not found"). A flow that exists but has page generators and no step
+            after them (no page processor or router) answers the same 404, enabled or disabled
+            (observed 2026-10-24), so the answer doesn't tell it from an unknown id: give the flow a
+            step after the export before running it. `POST /v1/flows/{_id}/test/run` refuses that flow
+            with a 404 of its own wording.
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/Error'
+              examples:
+                not_found:
+                  summary: Unknown flow id, or a flow with nothing after its page generators
+                  value:
+                    errors:
+                      - message: Flow not found
         '409':
           description: |-
             Another instance of this flow is already queued or running. Wait for it to
@@ -7492,14 +7507,19 @@ components:
             doneExporting:
               type: boolean
               readOnly: true
-              description: When true, all export pages have been generated.
+              description: |-
+                When true, all export pages have been generated. Observed exception: parent flow jobs
+                read false after their runs completed (runs of an HTTP export into an HTTP import, read
+                again minutes after they ended, 2026-10-23); `status` says whether a run finished.
             numPagesProcessed:
               type: integer
               readOnly: true
               description: |-
                 Number of pages processed by downstream steps: imports and lookup steps. A source export's
                 child job reads 0, a lookup step's and an import's count the pages they processed, and a
-                parent flow job sums its children.
+                parent flow job sums its children. Observed exception: on those same runs the parent read 0
+                while its import job read 1; when a parent reads 0, read the step jobs
+                (`GET /v1/jobs/{_id}/family`).
               examples:
                 - 10
             oIndex:

package/dist/job.yml

@@ -1599,14 +1599,19 @@ components:
             doneExporting:
               type: boolean
               readOnly: true
-              description: When true, all export pages have been generated.
+              description: |-
+                When true, all export pages have been generated. Observed exception: parent flow jobs
+                read false after their runs completed (runs of an HTTP export into an HTTP import, read
+                again minutes after they ended, 2026-10-23); `status` says whether a run finished.
             numPagesProcessed:
               type: integer
               readOnly: true
               description: |-
                 Number of pages processed by downstream steps: imports and lookup steps. A source export's
                 child job reads 0, a lookup step's and an import's count the pages they processed, and a
-                parent flow job sums its children.
+                parent flow job sums its children. Observed exception: on those same runs the parent read 0
+                while its import job read 1; when a parent reads 0, read the step jobs
+                (`GET /v1/jobs/{_id}/family`).
               examples:
                 - 10
             oIndex:

package/dist/tool.yml

@@ -31951,7 +31951,7 @@ components:
 
             When this export is the first lookup of a builder-mode API with `pagination.enabled` set, it is that API's volume driver: saving the export (even unchanged) invalidates the API's issued cursors, so a caller mid-walk gets an empty final page, and removing `paging` is accepted on save but makes every call to the API fail with `400 api_pagination_source_not_paged` until paging is restored or the API's flag is turned off.
 
-            When a next page's response is identical to the previous one, paging stops: the export records an open error with code `page_response_error` ("Identical response received from next page request. No more page requests will be made.") and the run completes with the pages already read, so later pages are never exported. A request that doesn't change between pages produces this, as observed with `method: page` and the pagination variable missing from the relative URI and body; reference the variable so each request asks for the next page.
+            When a next page's response is identical to the previous one, paging stops: the export records an open error with code `page_response_error` ("Identical response received from next page request. No more page requests will be made.") and later pages are never exported. A request that doesn't change between pages produces this, as observed with `method: page` and the pagination variable missing from the relative URI and body; reference the variable so each request asks for the next page. In that probe (an HTTP export, 2026-10-23) the run completed with the pages already read when the export had no `type`, and failed when it had `type: "delta"`: the steps after the export received nothing and the checkpoint didn't move. Other `type` values weren't tried. An invoke of that export, or a virtual export of the same document, answered 200 with the records read, then `{"errors": [...]}` carrying the `page_response_error`, as two JSON objects in one `text/plain` body.
           x-celigo-ai-guidance:
             - Configuration object for navigating through multi-page API responses.
             - |-

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@celigo/api-specs",
-  "version": "0.2.190",
+  "version": "0.2.191",
   "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": "c801232e",
+		"iasCommit": "1cd90c84",
 		"generatedAt": "2026-10-25"
 	},
 	"roots": {