@celigo/api-specs 0.2.190 → 0.2.192

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
@@ -2136,12 +2151,17 @@ paths:
         `pathToMany`, `childIndex`, `traceKey`) identify where in the pipeline the record was when it
         failed and how it's structured.
 
-        The `data` field is the record as it reached the failing step — on an HTTP import, before the
-        import's mappings, not the request the import sent. Use `PUT .../{retryDataKey}/data` to mutate
+        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
+        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),
-        `page_generator` means the error was upstream of the processor.
+        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),
+        `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.
       parameters:
         - name: _id
           in: path
@@ -7492,14 +7512,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:
@@ -7605,8 +7630,8 @@ components:
         `GET /v1/flows/{_id}/{_stepId}/{retryDataKey}/data` and accepted (full-replace) by the PUT on the
         same path.
 
-        The `data` field carries the record as it reached the failing step, which a retry runs through
-        that step again — its shape is adaptor-specific. The surrounding fields identify where in the
+        The `data` field carries the record as it reached the failing stage, and a retry resumes from
+        that stage (`stage`) — its shape is adaptor-specific. The surrounding fields identify where in the
         pipeline the failure happened and how the record was structured.
       properties:
         retryDataKey:
@@ -7616,16 +7641,28 @@ components:
             - 5f8d43a1b9e5a80011a35f2d-rdk-0
         data:
           description: |-
-            The record as it reached the step. On an HTTP import it is the incoming record, before the
+            The record as the failing stage held it, which depends on `stage`. At `page_processor_import`
+            (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. Shape varies by adaptor.
+            record. 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
         stage:
           type: string
-          description: Pipeline stage where the record was when the error occurred.
+          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).
           examples:
             - page_processor_import
+            - post_response_mapping
             - importMappingExtract
         pgExportId:
           type: string
@@ -7667,7 +7704,8 @@ components:
           additionalProperties: true
           description: |-
             Adaptor-level response envelope captured alongside the record payload. Present on failures
-            returned by an HTTP or import adaptor; carries fields like `data[]`, `errors[]`,
+            returned by an HTTP or import adaptor, and on a postResponseMap hook's errors, where it is the
+            destination's stored reply (`statusCode`, `id`, `_json`); carries fields like `data[]`, `errors[]`,
             `subGroupIdMapForSuccess`, `resultRecordIds`, `dataURIs`, `groupId`, `recordId`,
             and `ignoredResults`. Treat the shape as opaque — it varies by adaptor — and pass it through
             unchanged when PUT-ing the envelope back.

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.192",
   "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": "3e699444",
 		"generatedAt": "2026-10-25"
 	},
 	"roots": {