@celigo/api-specs 0.2.217 → 0.2.218

package/dist/export.yml

@@ -1461,6 +1461,18 @@ components:
               IMPORTANT: Ensure the field is not being updated by other processes, as this could
               cause records to be skipped unexpectedly. If multiple processes need to track exports,
               use separate boolean fields for each process.
+            - |-
+              On a NetSuite saved-search export the run pins the set of records to flag when it
+              starts and reads them from the front of the still-unflagged set, so records that
+              become eligible during the run wait for the next run — the pattern to recommend over
+              a type-`all` export whose flow sets the flag in a later NetSuite step. Correctness
+              then rests on Group rows, not on the Batch size limit: with `netsuite.skipGrouping:
+              false` (Group rows on, search sorted by Internal ID) every record of the pinned set
+              exported exactly once at a batch size of 5, with no duplicates when two records
+              became eligible mid-run (they waited for the next run); with Group rows
+              off on a search that returns several rows per record, the rows of a record that fall
+              after the page in which it was flagged are not exported and are not retried (83 of
+              134 transaction lines at a batch size of 1, 117 of 134 at 5).
           examples:
             - isExported
             - hasBeenSynced
@@ -10719,6 +10731,12 @@ components:
               Set `true` for an ad-hoc RESTlet search (criteria and columns without a saved
               search): grouping needs the search sorted by internal id, and an unsorted ad-hoc
               search fails with `[search_not_sorted]`.
+            - |-
+              With export type `once`, keep this `false` on a search that returns several rows per
+              record: `once` flags the record when the page holding its first row completes, and
+              with `true` the record's remaining rows drop out of the later requests — at a batch
+              size of 5, 17 of 134 transaction lines never exported. Grouped, the record is the
+              whole transaction and every row is exported exactly once.
             - 'For `exportSelect` / `refreshableSelect` dropdowns backed by a NetSuite RESTlet, set `skipGrouping: true`: the UI''s option mapper expects flat per-row results, and the platform otherwise wraps each row in its own grouping list (every option''s `label` then renders as `undefined`).'
         statsOnly:
           type: boolean
@@ -10940,6 +10958,22 @@ components:
                 and memory use per call; tune to the record's size. The RESTlet caps a call at 1000,
                 so a larger value acts as 1000. In a test run or preview the request is capped at the
                 export's `pageSize` (default 20) instead.
+              x-celigo-ai-guidance:
+                - |-
+                  Each request re-runs the saved search and returns the next slice by position, on
+                  the SuiteBundle and SuiteApp 2.0 RESTlets alike. Rows that enter the result set
+                  ahead of the position between two requests come back again — a contiguous block
+                  of duplicates equal to the rows that entered; rows that leave it are skipped with
+                  no error. A run whose rows fit in one request has no gap. The shift acts on
+                  positions, not on order: in the probes every row came back in one fixed per-row
+                  order (Internal ID, then line) on every run, and the inserted rows displaced them
+                  all the same. Export type `once` with `netsuite.skipGrouping: false` prevents it,
+                  because it pins the record set when the run starts.
+                - |-
+                  Leave this blank unless a NetSuite time limit forced a smaller value: a smaller
+                  batch multiplies the request boundaries per run, and each one is exposed when
+                  the search's membership changes mid-run (an older record approved, a flag the
+                  search filters on reset).
               examples:
                 - 100
                 - 200

package/dist/tool.yml

@@ -27851,6 +27851,18 @@ components:
               IMPORTANT: Ensure the field is not being updated by other processes, as this could
               cause records to be skipped unexpectedly. If multiple processes need to track exports,
               use separate boolean fields for each process.
+            - |-
+              On a NetSuite saved-search export the run pins the set of records to flag when it
+              starts and reads them from the front of the still-unflagged set, so records that
+              become eligible during the run wait for the next run — the pattern to recommend over
+              a type-`all` export whose flow sets the flag in a later NetSuite step. Correctness
+              then rests on Group rows, not on the Batch size limit: with `netsuite.skipGrouping:
+              false` (Group rows on, search sorted by Internal ID) every record of the pinned set
+              exported exactly once at a batch size of 5, with no duplicates when two records
+              became eligible mid-run (they waited for the next run); with Group rows
+              off on a search that returns several rows per record, the rows of a record that fall
+              after the page in which it was flagged are not exported and are not retried (83 of
+              134 transaction lines at a batch size of 1, 117 of 134 at 5).
           examples:
             - isExported
             - hasBeenSynced
@@ -36614,6 +36626,12 @@ components:
               Set `true` for an ad-hoc RESTlet search (criteria and columns without a saved
               search): grouping needs the search sorted by internal id, and an unsorted ad-hoc
               search fails with `[search_not_sorted]`.
+            - |-
+              With export type `once`, keep this `false` on a search that returns several rows per
+              record: `once` flags the record when the page holding its first row completes, and
+              with `true` the record's remaining rows drop out of the later requests — at a batch
+              size of 5, 17 of 134 transaction lines never exported. Grouped, the record is the
+              whole transaction and every row is exported exactly once.
             - 'For `exportSelect` / `refreshableSelect` dropdowns backed by a NetSuite RESTlet, set `skipGrouping: true`: the UI''s option mapper expects flat per-row results, and the platform otherwise wraps each row in its own grouping list (every option''s `label` then renders as `undefined`).'
         statsOnly:
           type: boolean
@@ -36835,6 +36853,22 @@ components:
                 and memory use per call; tune to the record's size. The RESTlet caps a call at 1000,
                 so a larger value acts as 1000. In a test run or preview the request is capped at the
                 export's `pageSize` (default 20) instead.
+              x-celigo-ai-guidance:
+                - |-
+                  Each request re-runs the saved search and returns the next slice by position, on
+                  the SuiteBundle and SuiteApp 2.0 RESTlets alike. Rows that enter the result set
+                  ahead of the position between two requests come back again — a contiguous block
+                  of duplicates equal to the rows that entered; rows that leave it are skipped with
+                  no error. A run whose rows fit in one request has no gap. The shift acts on
+                  positions, not on order: in the probes every row came back in one fixed per-row
+                  order (Internal ID, then line) on every run, and the inserted rows displaced them
+                  all the same. Export type `once` with `netsuite.skipGrouping: false` prevents it,
+                  because it pins the record set when the run starts.
+                - |-
+                  Leave this blank unless a NetSuite time limit forced a smaller value: a smaller
+                  batch multiplies the request boundaries per run, and each one is exposed when
+                  the search's membership changes mid-run (an older record approved, a flag the
+                  search filters on reset).
               examples:
                 - 100
                 - 200

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@celigo/api-specs",
-  "version": "0.2.217",
+  "version": "0.2.218",
   "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": "d89238ad",
+		"iasCommit": "a159c7c3",
 		"generatedAt": "2026-11-02"
 	},
 	"roots": {