@celigo/api-specs 0.2.147 → 0.2.148

package/dist/export.yml

@@ -984,10 +984,13 @@ components:
       description: |-
         Configures incremental exports that retrieve only records created or modified since the last
         successful run. Required when the export's type is "delta"; omit for other export types.
-        When no cutoff is supplied, the platform-managed last-successful-run timestamp (exposed as
-        {{lastExportDateTime}}) is the lower bound — the first run behaves like a full export, and
-        after a failed run the next run reuses the last successful timestamp so changed records are
-        not missed.
+        The platform-managed last-successful-run timestamp (exposed as {{lastExportDateTime}}) is the
+        lower bound, and after a failed run the next run reuses the last successful timestamp so
+        changed records are not missed. A first run is not a full export: with no `startDate`, its
+        {{lastExportDateTime}} is the run's own timestamp (the value {{currentExportDateTime}} also
+        holds), so it picks up no earlier changes. Set `startDate` to reach back further. On success,
+        when `POST /v1/flows/{_id}/run` sends `export.endDate`, the flow's checkpoint is left at that
+        value, so an end date in the past moves the next run's lower bound back.
       x-celigo-ai-guidance:
         - |-
           This object is REQUIRED when the export's type field is set to "delta" and
@@ -1023,7 +1026,7 @@ components:
 
           2. The system automatically maintains the last successful run timestamp
               - No need to store or manage timestamps in your own code
-              - First run fetches all records (equivalent to a standard export)
+              - A first run without ``startDate`` fetches nothing older than the run itself
               - Subsequent runs use this timestamp as the starting point
 
           3. Error handling and recovery:
@@ -1245,9 +1248,9 @@ components:
             - 'null'
           format: date-time
           description: |-
-            Explicit lower-bound cutoff for the first run, overriding the default of starting from the
-            beginning of time. Subsequent runs use the platform-managed last-successful-run timestamp.
-            Set it to backfill from a specific point rather than exporting all history.
+            Lower-bound cutoff for the first run. Omitting it doesn't export history: the first run
+            then starts at its own timestamp. Set it to the earliest change the first run should pick
+            up. Subsequent runs use the platform-managed last-successful-run timestamp.
           x-celigo-ai-guidance:
             - |-
               Initial cutoff timestamp for the first export run, in ISO-8601 UTC format (e.g.

package/dist/flow.yml

@@ -824,8 +824,9 @@ paths:
 
         The request body is optional. When omitted, the flow runs with its configured schedule behavior —
         for delta flows this means using the current `lastExportDateTime` as the lower bound. Pass
-        `export.startDate` / `export.endDate` to override the delta window for this run only (the flow's
-        checkpoint still advances on success). Pass `_exportIds` to limit execution to a subset of the flow's
+        `export.startDate` / `export.endDate` to set this run's delta window. On success, when
+        `export.endDate` is sent, the flow's checkpoint is left at that value, so an end date in the past
+        moves the next run's lower bound back. Pass `_exportIds` to limit execution to a subset of the flow's
         generators (useful for flows with many independent sources).
 
         Flow-level preconditions enforced by the platform:
@@ -835,8 +836,9 @@ paths:
 
         To trace a run end-to-end, arm debug logging before calling this, then use the returned
         `_jobId` with the execution-log endpoints. For delta backfills, prefer passing explicit
-        `startDate`/`endDate` over editing the export's `lastExportDateTime` — the override is
-        scoped to one run. A flow runs one instance at a time: a run requested while another
+        `startDate`/`endDate` over editing the export's `lastExportDateTime`, and read the checkpoint
+        first (`GET /v1/flows/{_id}/lastExportDateTime`): the override doesn't stay with one run, since
+        a successful run that sends `endDate` leaves the checkpoint there. A flow runs one instance at a time: a run requested while another
         instance is queued or running is refused with `409 job_already_queued` ("Another instance
         for this flow is already queued or running"), and a run-next-flow trigger that arrives in
         that state is dropped rather than queued.
@@ -1080,11 +1082,14 @@ paths:
         generators (exports) in the flow. This value is what gets substituted into the `{{lastExportDateTime}}`
         Handlebars variable on the next delta run of any export in the flow.
 
-        The checkpoint advances automatically at the end of a successful delta run. It can be overridden per
-        run by passing `export.startDate` / `export.endDate` to `POST /v1/flows/{_id}/run`.
+        The checkpoint advances automatically at the end of a successful delta run. On success, when
+        `POST /v1/flows/{_id}/run` sends `export.endDate`, the checkpoint is left at that value, so an end
+        date in the past moves the next run's lower bound back.
 
-        A missing or very old value means the next delta run will re-scan the full history window from
-        the source. This is the flow-scoped checkpoint; per-export checkpoints (for flows with multiple
+        A missing value (`null`, a flow that has never run) is not a full re-scan: the next delta run's
+        `{{lastExportDateTime}}` is the export's `delta.startDate` when set, and otherwise the run's own
+        timestamp, which picks up no earlier changes. A very old value re-reads everything changed since
+        then. This is the flow-scoped checkpoint; per-export checkpoints (for flows with multiple
         generators that advance independently) are exposed on the export record's `delta` block.
       parameters:
         - name: _id

package/dist/tool.yml

@@ -25833,10 +25833,13 @@ components:
       description: |-
         Configures incremental exports that retrieve only records created or modified since the last
         successful run. Required when the export's type is "delta"; omit for other export types.
-        When no cutoff is supplied, the platform-managed last-successful-run timestamp (exposed as
-        {{lastExportDateTime}}) is the lower bound — the first run behaves like a full export, and
-        after a failed run the next run reuses the last successful timestamp so changed records are
-        not missed.
+        The platform-managed last-successful-run timestamp (exposed as {{lastExportDateTime}}) is the
+        lower bound, and after a failed run the next run reuses the last successful timestamp so
+        changed records are not missed. A first run is not a full export: with no `startDate`, its
+        {{lastExportDateTime}} is the run's own timestamp (the value {{currentExportDateTime}} also
+        holds), so it picks up no earlier changes. Set `startDate` to reach back further. On success,
+        when `POST /v1/flows/{_id}/run` sends `export.endDate`, the flow's checkpoint is left at that
+        value, so an end date in the past moves the next run's lower bound back.
       x-celigo-ai-guidance:
         - |-
           This object is REQUIRED when the export's type field is set to "delta" and
@@ -25872,7 +25875,7 @@ components:
 
           2. The system automatically maintains the last successful run timestamp
               - No need to store or manage timestamps in your own code
-              - First run fetches all records (equivalent to a standard export)
+              - A first run without ``startDate`` fetches nothing older than the run itself
               - Subsequent runs use this timestamp as the starting point
 
           3. Error handling and recovery:
@@ -26094,9 +26097,9 @@ components:
             - 'null'
           format: date-time
           description: |-
-            Explicit lower-bound cutoff for the first run, overriding the default of starting from the
-            beginning of time. Subsequent runs use the platform-managed last-successful-run timestamp.
-            Set it to backfill from a specific point rather than exporting all history.
+            Lower-bound cutoff for the first run. Omitting it doesn't export history: the first run
+            then starts at its own timestamp. Set it to the earliest change the first run should pick
+            up. Subsequent runs use the platform-managed last-successful-run timestamp.
           x-celigo-ai-guidance:
             - |-
               Initial cutoff timestamp for the first export run, in ISO-8601 UTC format (e.g.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@celigo/api-specs",
-  "version": "0.2.147",
+  "version": "0.2.148",
   "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": "53d752ea",
+		"iasCommit": "c5f16e90",
 		"generatedAt": "2026-10-21"
 	},
 	"roots": {