@celigo/api-specs 0.2.191 → 0.2.192

package/dist/flow.yml

@@ -2151,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
@@ -7625,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:
@@ -7636,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
@@ -7687,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/package.json

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