@celigo/api-specs 0.2.56 → 0.2.58

package/dist/export.yml

@@ -7634,7 +7634,7 @@ components:
                 - recordId
             successPath:
               type: string
-              description: Path to a response field that signals whether the call succeeded, for APIs that return HTTP 200 even on failure. Must be used with `successValues` to define which values at this path count as success.
+              description: 'Path to a response field that signals whether the call succeeded, for APIs that return HTTP 200 even on failure. With `successValues`, the value at this path must match one of them; without `successValues`, the path only has to resolve — a response in which it is absent fails with `response_failure` ("Unable to extract paths from response body using path: <path>, Response: …").'
               x-celigo-ai-guidance:
                 - |-
                   Use this when the API returns HTTP 200 for all requests but signals success or
@@ -7642,6 +7642,25 @@ components:
                 - |-
                   Example: If the API returns `{"status": "ok", "data": [...]}`,
                   set `successPath` to `status` and `successValues` to `["ok"]`.
+                - |-
+                  On a LOOKUP step this is also the way to make "no match" fail the record. A lookup
+                  whose `resourcePath` resolves to nothing returns zero records and the platform counts
+                  that as success: the record continues to the next step with nothing merged, and the
+                  flow's `pageProcessors[].proceedOnFailure` for that step has no bearing on it. Set
+                  `successPath` (no `successValues`) to a path that exists only when a match was found,
+                  e.g. `results[0].id`: an empty result then fails the record with `response_failure`
+                  (`Unable to extract paths from response body using path: results[0].id, Response:
+                  {…}`), and `proceedOnFailure: true` on that step lets the failed record continue.
+                  Live-verified 2026-09-24 in real flow runs (listener -> HTTP lookup -> import, one
+                  record each): empty result with no `successPath` -> lookup 1 success, import 1
+                  success, with or without `proceedOnFailure`; `successPath` on an absent path ->
+                  lookup 1 error with that message, import 0 (1 with `proceedOnFailure: true`);
+                  `successPath` on a present path -> success. The error text is generic; for a custom
+                  message a `preSavePage` hook on the lookup that returns one `newErrorsAndRetryData`
+                  entry (`{errors: [{code: 404, message: "Product not found"}]}`) when `options.data`
+                  and `options.errors` are both empty failed the record with "Product not found" in
+                  the same runs. Lookups on adaptors without HTTP response settings (NetSuite, for
+                  example) have no `successPath`.
               examples:
                 - status
                 - success

package/dist/tool.yml

@@ -30628,7 +30628,7 @@ components:
                 - recordId
             successPath:
               type: string
-              description: Path to a response field that signals whether the call succeeded, for APIs that return HTTP 200 even on failure. Must be used with `successValues` to define which values at this path count as success.
+              description: 'Path to a response field that signals whether the call succeeded, for APIs that return HTTP 200 even on failure. With `successValues`, the value at this path must match one of them; without `successValues`, the path only has to resolve — a response in which it is absent fails with `response_failure` ("Unable to extract paths from response body using path: <path>, Response: …").'
               x-celigo-ai-guidance:
                 - |-
                   Use this when the API returns HTTP 200 for all requests but signals success or
@@ -30636,6 +30636,25 @@ components:
                 - |-
                   Example: If the API returns `{"status": "ok", "data": [...]}`,
                   set `successPath` to `status` and `successValues` to `["ok"]`.
+                - |-
+                  On a LOOKUP step this is also the way to make "no match" fail the record. A lookup
+                  whose `resourcePath` resolves to nothing returns zero records and the platform counts
+                  that as success: the record continues to the next step with nothing merged, and the
+                  flow's `pageProcessors[].proceedOnFailure` for that step has no bearing on it. Set
+                  `successPath` (no `successValues`) to a path that exists only when a match was found,
+                  e.g. `results[0].id`: an empty result then fails the record with `response_failure`
+                  (`Unable to extract paths from response body using path: results[0].id, Response:
+                  {…}`), and `proceedOnFailure: true` on that step lets the failed record continue.
+                  Live-verified 2026-09-24 in real flow runs (listener -> HTTP lookup -> import, one
+                  record each): empty result with no `successPath` -> lookup 1 success, import 1
+                  success, with or without `proceedOnFailure`; `successPath` on an absent path ->
+                  lookup 1 error with that message, import 0 (1 with `proceedOnFailure: true`);
+                  `successPath` on a present path -> success. The error text is generic; for a custom
+                  message a `preSavePage` hook on the lookup that returns one `newErrorsAndRetryData`
+                  entry (`{errors: [{code: 404, message: "Product not found"}]}`) when `options.data`
+                  and `options.errors` are both empty failed the record with "Product not found" in
+                  the same runs. Lookups on adaptors without HTTP response settings (NetSuite, for
+                  example) have no `successPath`.
               examples:
                 - status
                 - success

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@celigo/api-specs",
-  "version": "0.2.56",
+  "version": "0.2.58",
   "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": "cca55af",
+		"iasCommit": "03589ea",
 		"generatedAt": "2026-09-25"
 	},
 	"roots": {