@celigo/api-specs 0.2.186 → 0.2.188

package/dist/api.yml

@@ -8017,7 +8017,23 @@ components:
             `auth.type` `oauth` (including the `azureserviceprincipal` service principal an Azure
             Data Lake Storage Gen2 connection authenticates with and the `googleserviceaccount` key
             a Google Cloud Storage connection uses), or the `awsIam` role for `auth.type` `awsiam`.
-            Must belong to the same account as the connection. Omit for every other auth type.
+            Must belong to the same account as the connection — or be the iClient Celigo publishes
+            with a pre-built OAuth HTTP connector (pre-configured by the connector; from the
+            connecting account `GET /v1/iclients/{_id}` on it is 404 resource_not_found and
+            `GET /v1/iclients` does not list it, yet the connection saves with it). Omit for every
+            other auth type. On a Shopify connection `settings.appType` says which of the two it
+            is: `public` rides Celigo's published Shopify app (installed from the Shopify App
+            Store), `custom` rides the account's own iClient — the Shopify app the customer created
+            in the Shopify dev dashboard — with `auth.oauth.scope` chosen on the connection. A
+            connection with no `settings.appType` (saved before the App type existed) rides the
+            published app when its `_iClientId` is the connector's published iClient — the form
+            opens it with no App type selected and it keeps working — and an account-owned iClient
+            otherwise. A saved Public App connection, with or without a stored `settings.appType`,
+            moves to the customer's app by the same re-save: `settings.appType` `custom`, its own
+            `_iClientId` and scopes, then authorizing; the connection form does not offer the
+            reverse, because the Public App flow is authorized from the Shopify App Store and
+            creates a new connection. Integration App connections (`_connectorId`) stay on Celigo's
+            published app and carry no `settings.appType`.
           examples:
             - 6203a7e4f321d800129a1b8e
           x-celigo-ui-override: 'Required by the connection form for oauth (subForms/httpOAuth.js: required true, iClient filter provider custom_oauth2, or googleserviceaccount / azureserviceprincipal for the GCS and ADLS Gen2 variants) and for awsIam (subForms/httpAwsIam.js: required true, filter provider awsIam). For oauth the API creates the connection without it and the authorization is completed afterward; for awsiam the API also rejects its absence (see the if/then rule on this schema).'
@@ -8038,7 +8054,20 @@ components:
             - |-
               The iClient must belong to the same account as the connection — an iClient id from
               another account fails with 422 invalid_ref "The referenced IClient must belong to the
-              same user."
+              same user." The one exception is the iClient a pre-built OAuth HTTP connector
+              pre-configures (Celigo's published app — the Shopify Public App's, for one): the
+              connection saves with that id from the connecting account even though
+              `GET /v1/iclients/{_id}` on it is 404 there, so do not refuse a `public` Shopify
+              connection on this rule.
+            - |-
+              On a Shopify connection keep `settings.appType` and `_iClientId` in step the way the
+              form does — `public` with the connector's published iClient, `custom` with an
+              account-owned iClient: the API saves either value of `settings.appType` beside either
+              iClient (and any other string under `settings.appType`) — nothing server-side checks
+              the pair, so the form's rule is the only guard. On an update never drop `_iClientId` from
+              an `auth.type` `oauth` connection: 422 invalid_field_update "Removing _iClientId is
+              not allowed for oauth connections due to security reasons." — switch it to another
+              iClient instead.
         _httpConnectorId:
           type: string
           format: objectId

package/dist/connection.yml

@@ -6636,7 +6636,23 @@ components:
             `auth.type` `oauth` (including the `azureserviceprincipal` service principal an Azure
             Data Lake Storage Gen2 connection authenticates with and the `googleserviceaccount` key
             a Google Cloud Storage connection uses), or the `awsIam` role for `auth.type` `awsiam`.
-            Must belong to the same account as the connection. Omit for every other auth type.
+            Must belong to the same account as the connection — or be the iClient Celigo publishes
+            with a pre-built OAuth HTTP connector (pre-configured by the connector; from the
+            connecting account `GET /v1/iclients/{_id}` on it is 404 resource_not_found and
+            `GET /v1/iclients` does not list it, yet the connection saves with it). Omit for every
+            other auth type. On a Shopify connection `settings.appType` says which of the two it
+            is: `public` rides Celigo's published Shopify app (installed from the Shopify App
+            Store), `custom` rides the account's own iClient — the Shopify app the customer created
+            in the Shopify dev dashboard — with `auth.oauth.scope` chosen on the connection. A
+            connection with no `settings.appType` (saved before the App type existed) rides the
+            published app when its `_iClientId` is the connector's published iClient — the form
+            opens it with no App type selected and it keeps working — and an account-owned iClient
+            otherwise. A saved Public App connection, with or without a stored `settings.appType`,
+            moves to the customer's app by the same re-save: `settings.appType` `custom`, its own
+            `_iClientId` and scopes, then authorizing; the connection form does not offer the
+            reverse, because the Public App flow is authorized from the Shopify App Store and
+            creates a new connection. Integration App connections (`_connectorId`) stay on Celigo's
+            published app and carry no `settings.appType`.
           examples:
             - 6203a7e4f321d800129a1b8e
           x-celigo-ui-override: 'Required by the connection form for oauth (subForms/httpOAuth.js: required true, iClient filter provider custom_oauth2, or googleserviceaccount / azureserviceprincipal for the GCS and ADLS Gen2 variants) and for awsIam (subForms/httpAwsIam.js: required true, filter provider awsIam). For oauth the API creates the connection without it and the authorization is completed afterward; for awsiam the API also rejects its absence (see the if/then rule on this schema).'
@@ -6657,7 +6673,20 @@ components:
             - |-
               The iClient must belong to the same account as the connection — an iClient id from
               another account fails with 422 invalid_ref "The referenced IClient must belong to the
-              same user."
+              same user." The one exception is the iClient a pre-built OAuth HTTP connector
+              pre-configures (Celigo's published app — the Shopify Public App's, for one): the
+              connection saves with that id from the connecting account even though
+              `GET /v1/iclients/{_id}` on it is 404 there, so do not refuse a `public` Shopify
+              connection on this rule.
+            - |-
+              On a Shopify connection keep `settings.appType` and `_iClientId` in step the way the
+              form does — `public` with the connector's published iClient, `custom` with an
+              account-owned iClient: the API saves either value of `settings.appType` beside either
+              iClient (and any other string under `settings.appType`) — nothing server-side checks
+              the pair, so the form's rule is the only guard. On an update never drop `_iClientId` from
+              an `auth.type` `oauth` connection: 422 invalid_field_update "Removing _iClientId is
+              not allowed for oauth connections due to security reasons." — switch it to another
+              iClient instead.
         _httpConnectorId:
           type: string
           format: objectId

package/dist/enduser.yml

@@ -4687,7 +4687,23 @@ components:
             `auth.type` `oauth` (including the `azureserviceprincipal` service principal an Azure
             Data Lake Storage Gen2 connection authenticates with and the `googleserviceaccount` key
             a Google Cloud Storage connection uses), or the `awsIam` role for `auth.type` `awsiam`.
-            Must belong to the same account as the connection. Omit for every other auth type.
+            Must belong to the same account as the connection — or be the iClient Celigo publishes
+            with a pre-built OAuth HTTP connector (pre-configured by the connector; from the
+            connecting account `GET /v1/iclients/{_id}` on it is 404 resource_not_found and
+            `GET /v1/iclients` does not list it, yet the connection saves with it). Omit for every
+            other auth type. On a Shopify connection `settings.appType` says which of the two it
+            is: `public` rides Celigo's published Shopify app (installed from the Shopify App
+            Store), `custom` rides the account's own iClient — the Shopify app the customer created
+            in the Shopify dev dashboard — with `auth.oauth.scope` chosen on the connection. A
+            connection with no `settings.appType` (saved before the App type existed) rides the
+            published app when its `_iClientId` is the connector's published iClient — the form
+            opens it with no App type selected and it keeps working — and an account-owned iClient
+            otherwise. A saved Public App connection, with or without a stored `settings.appType`,
+            moves to the customer's app by the same re-save: `settings.appType` `custom`, its own
+            `_iClientId` and scopes, then authorizing; the connection form does not offer the
+            reverse, because the Public App flow is authorized from the Shopify App Store and
+            creates a new connection. Integration App connections (`_connectorId`) stay on Celigo's
+            published app and carry no `settings.appType`.
           examples:
             - 6203a7e4f321d800129a1b8e
           x-celigo-ui-override: 'Required by the connection form for oauth (subForms/httpOAuth.js: required true, iClient filter provider custom_oauth2, or googleserviceaccount / azureserviceprincipal for the GCS and ADLS Gen2 variants) and for awsIam (subForms/httpAwsIam.js: required true, filter provider awsIam). For oauth the API creates the connection without it and the authorization is completed afterward; for awsiam the API also rejects its absence (see the if/then rule on this schema).'
@@ -4708,7 +4724,20 @@ components:
             - |-
               The iClient must belong to the same account as the connection — an iClient id from
               another account fails with 422 invalid_ref "The referenced IClient must belong to the
-              same user."
+              same user." The one exception is the iClient a pre-built OAuth HTTP connector
+              pre-configures (Celigo's published app — the Shopify Public App's, for one): the
+              connection saves with that id from the connecting account even though
+              `GET /v1/iclients/{_id}` on it is 404 there, so do not refuse a `public` Shopify
+              connection on this rule.
+            - |-
+              On a Shopify connection keep `settings.appType` and `_iClientId` in step the way the
+              form does — `public` with the connector's published iClient, `custom` with an
+              account-owned iClient: the API saves either value of `settings.appType` beside either
+              iClient (and any other string under `settings.appType`) — nothing server-side checks
+              the pair, so the form's rule is the only guard. On an update never drop `_iClientId` from
+              an `auth.type` `oauth` connection: 422 invalid_field_update "Removing _iClientId is
+              not allowed for oauth connections due to security reasons." — switch it to another
+              iClient instead.
         _httpConnectorId:
           type: string
           format: objectId

package/dist/flow.yml

@@ -5561,16 +5561,24 @@ components:
             schedule_not_supported` when its runs would be less than a minute apart — which
             is also what free text such as `every 5 minutes` produces.
 
-            A save can store a later minute than it was sent. A minute field that is 0, 15,
-            30 or 45, a list made only of those minutes, a range that starts at minute 0, or a
-            `*/N` step with N above 5 is stored 5 minutes later: `? 0 6 ? * *` as
-            `? 5 6 ? * *`, `? 0,15,30,45 * ? * *` as `? 5,20,35,50 * ? * *`, `? 0-10 * ? * *`
-            as `? 5-15 * ? * *`, and `? */15 * ? * *` as `? 5-59/15 * ? * *`. Any other minute
-            field is kept as sent, including `? */5 * * * *` and lists that mix in other
-            minutes (`? 0,10,20,30,40,50 * ? * *`), and the other fields never change. POST,
-            PUT and PATCH all store it this way, the response and later reads return the
-            stored value, and scheduled runs start at the stored minutes, so a flow saved for
-            06:00 runs at 06:05 (live-verified 2026-10-22).
+            Celigo spreads scheduled starts across the platform so that every flow starts
+            promptly: you choose the cadence — every N minutes, hourly, daily, twice daily,
+            weekly, or any cron pattern — Celigo assigns the exact start minute within it
+            (kept as written or moved, as below), and scheduled runs start at the stored
+            minute, as soon as possible after it when the platform is busy. Today a
+            minute field of 0, 15, 30 or 45, a list made only of those minutes, a range that
+            starts at minute 0, or a `*/N` step with N above 5 is stored 5 minutes later —
+            `? 0 6 ? * *` as `? 5 6 ? * *`, `? 0,15,30,45 * ? * *` as `? 5,20,35,50 * ? * *`,
+            `? 0-10 * ? * *` as `? 5-15 * ? * *`, and `? */15 * ? * *` as
+            `? 5-59/15 * ? * *` — while other minute fields (`? */5 * * * *`) are kept as sent
+            and the other fields never change (live-verified 2026-10-22). The assigned minute
+            is the platform's current policy, not a contract — Celigo may assign different
+            minutes as it rebalances start times — so the stored `schedule`, what POST, PUT
+            and PATCH return and later reads show, is the only source of the minute a flow
+            runs at: a flow saved for 06:00 runs at the stored 06:05. For a run that must
+            begin at a particular minute, your own scheduler POSTs `/v1/flows/{_id}/run` at
+            that minute: the call queues an on-demand run, accepts no start time in its body,
+            and answers `409 job_already_queued` while another instance is queued or running.
           x-celigo-ai-guidance:
             - |-
               Build `schedule` as a Celigo 6-field cron:
@@ -5592,15 +5600,33 @@ components:
               schedule (`? * * ? * *`) with 422 `invalid_value`. Fix or clear the schedule
               instead of disabling the flow to get past the error.
             - |-
-              When AUTHORING a schedule, read `schedule` back after the save and give
-              the user the stored times, not the requested ones: a schedule written
-              for minute 0, 15, 30 or 45 can be stored, and run, 5 minutes later (see
-              the description), and an explicit list is moved the same way as a step
-              form. Hourly or longer: minute `5` with an explicit hour list
-              (`? 5 0,4,8,12,16,20 ? * *` = every 4 hours;
-              `? 5 9 ? * 1,2,3,4,5` = weekdays 9:05 AM; `? 5 0 ? * *` = daily at
-              00:05); sub-hourly: an explicit minute list with hour `*`
-              (`? 5,20,35,50 * ? * *` = every 15 minutes) or a step form.
+              When AUTHORING a schedule, write the cadence in the shape the platform
+              keeps today — hourly or longer, minute `5` with an explicit hour list
+              (`? 5 0,4,8,12,16,20 ? * *` = every 4 hours; `? 5 9 ? * 1,2,3,4,5` =
+              weekdays 9:05 AM; `? 5 0 ? * *` = daily at 00:05); sub-hourly, an
+              explicit minute list with hour `*` (`? 5,20,35,50 * ? * *` = every 15
+              minutes) or a step form — and tell the user the start minute the platform
+              assigned: the requested minute when it is kept as sent (9:05 stays 9:05),
+              the shifted one when it is not — a schedule written for minute 0, 15, 30
+              or 45 is stored, and runs, 5 minutes later today (see the description),
+              and an explicit list is moved the same way as a step form. After a direct
+              save, read `schedule` back and report what was stored; when the write is
+              staged for approval instead of saved, state the minute the current rule
+              assigns rather than waiting to read it back. Never present `? 0 5 ? * *`
+              as a 5:00 run.
+            - |-
+              When a user asks for a flow to start at an exact minute (5:00 sharp, on
+              the hour), lead with what the platform does for them — starts are spread
+              across the platform so every flow starts promptly, and each run starts at
+              its stored minute, as soon as possible after it when the platform is busy
+              — then say the cadence is
+              theirs to choose and the start minute is Celigo's to assign, and offer the
+              nearest assigned minutes (today 4:50 or 5:05 around 5:00) or a run the
+              user's own scheduler requests at that minute with
+              `POST /v1/flows/{_id}/run`, which queues an on-demand run (409
+              `job_already_queued` while an instance is already queued or running). Do
+              not assemble a minute list or another expression shape to force a
+              particular minute.
             - |-
               Wildcard/step/range forms (`? */5 * * * *`, `? 10-59/30 * * * *`) are
               valid and the scheduler runs them — never claim an existing schedule's

package/dist/iclient.yml

@@ -595,6 +595,14 @@ components:
           type: string
           description: Authentication provider that determines which credential fields apply.
           x-celigo-ai-guidance:
+            - |-
+              An OAuth app the customer registers for a pre-built HTTP connector — a Shopify Custom
+              App created in the Shopify dev dashboard, for example — is a `custom_oauth2` iClient
+              with `_httpConnectorId` (and `_httpConnectorApiId`) pointing at that connector: the
+              shape the connection form's iClient editor saves, and the one its OAuth iClient picker
+              lists (subForms/httpOAuth.js filters on provider custom_oauth2). The API also accepts a
+              connector-named provider such as `shopify` on an account-created iClient, but the form
+              never saves one, so prefer `custom_oauth2`.
             - |-
               ## IMPORTANT NOTES:
               - This is not a human/vendor label — it is the provider key that selects an authentication method.

package/dist/mcp-server.yml

@@ -6523,7 +6523,23 @@ components:
             `auth.type` `oauth` (including the `azureserviceprincipal` service principal an Azure
             Data Lake Storage Gen2 connection authenticates with and the `googleserviceaccount` key
             a Google Cloud Storage connection uses), or the `awsIam` role for `auth.type` `awsiam`.
-            Must belong to the same account as the connection. Omit for every other auth type.
+            Must belong to the same account as the connection — or be the iClient Celigo publishes
+            with a pre-built OAuth HTTP connector (pre-configured by the connector; from the
+            connecting account `GET /v1/iclients/{_id}` on it is 404 resource_not_found and
+            `GET /v1/iclients` does not list it, yet the connection saves with it). Omit for every
+            other auth type. On a Shopify connection `settings.appType` says which of the two it
+            is: `public` rides Celigo's published Shopify app (installed from the Shopify App
+            Store), `custom` rides the account's own iClient — the Shopify app the customer created
+            in the Shopify dev dashboard — with `auth.oauth.scope` chosen on the connection. A
+            connection with no `settings.appType` (saved before the App type existed) rides the
+            published app when its `_iClientId` is the connector's published iClient — the form
+            opens it with no App type selected and it keeps working — and an account-owned iClient
+            otherwise. A saved Public App connection, with or without a stored `settings.appType`,
+            moves to the customer's app by the same re-save: `settings.appType` `custom`, its own
+            `_iClientId` and scopes, then authorizing; the connection form does not offer the
+            reverse, because the Public App flow is authorized from the Shopify App Store and
+            creates a new connection. Integration App connections (`_connectorId`) stay on Celigo's
+            published app and carry no `settings.appType`.
           examples:
             - 6203a7e4f321d800129a1b8e
           x-celigo-ui-override: 'Required by the connection form for oauth (subForms/httpOAuth.js: required true, iClient filter provider custom_oauth2, or googleserviceaccount / azureserviceprincipal for the GCS and ADLS Gen2 variants) and for awsIam (subForms/httpAwsIam.js: required true, filter provider awsIam). For oauth the API creates the connection without it and the authorization is completed afterward; for awsiam the API also rejects its absence (see the if/then rule on this schema).'
@@ -6544,7 +6560,20 @@ components:
             - |-
               The iClient must belong to the same account as the connection — an iClient id from
               another account fails with 422 invalid_ref "The referenced IClient must belong to the
-              same user."
+              same user." The one exception is the iClient a pre-built OAuth HTTP connector
+              pre-configures (Celigo's published app — the Shopify Public App's, for one): the
+              connection saves with that id from the connecting account even though
+              `GET /v1/iclients/{_id}` on it is 404 there, so do not refuse a `public` Shopify
+              connection on this rule.
+            - |-
+              On a Shopify connection keep `settings.appType` and `_iClientId` in step the way the
+              form does — `public` with the connector's published iClient, `custom` with an
+              account-owned iClient: the API saves either value of `settings.appType` beside either
+              iClient (and any other string under `settings.appType`) — nothing server-side checks
+              the pair, so the form's rule is the only guard. On an update never drop `_iClientId` from
+              an `auth.type` `oauth` connection: 422 invalid_field_update "Removing _iClientId is
+              not allowed for oauth connections due to security reasons." — switch it to another
+              iClient instead.
         _httpConnectorId:
           type: string
           format: objectId

package/dist/tool.yml

@@ -10057,7 +10057,23 @@ components:
             `auth.type` `oauth` (including the `azureserviceprincipal` service principal an Azure
             Data Lake Storage Gen2 connection authenticates with and the `googleserviceaccount` key
             a Google Cloud Storage connection uses), or the `awsIam` role for `auth.type` `awsiam`.
-            Must belong to the same account as the connection. Omit for every other auth type.
+            Must belong to the same account as the connection — or be the iClient Celigo publishes
+            with a pre-built OAuth HTTP connector (pre-configured by the connector; from the
+            connecting account `GET /v1/iclients/{_id}` on it is 404 resource_not_found and
+            `GET /v1/iclients` does not list it, yet the connection saves with it). Omit for every
+            other auth type. On a Shopify connection `settings.appType` says which of the two it
+            is: `public` rides Celigo's published Shopify app (installed from the Shopify App
+            Store), `custom` rides the account's own iClient — the Shopify app the customer created
+            in the Shopify dev dashboard — with `auth.oauth.scope` chosen on the connection. A
+            connection with no `settings.appType` (saved before the App type existed) rides the
+            published app when its `_iClientId` is the connector's published iClient — the form
+            opens it with no App type selected and it keeps working — and an account-owned iClient
+            otherwise. A saved Public App connection, with or without a stored `settings.appType`,
+            moves to the customer's app by the same re-save: `settings.appType` `custom`, its own
+            `_iClientId` and scopes, then authorizing; the connection form does not offer the
+            reverse, because the Public App flow is authorized from the Shopify App Store and
+            creates a new connection. Integration App connections (`_connectorId`) stay on Celigo's
+            published app and carry no `settings.appType`.
           examples:
             - 6203a7e4f321d800129a1b8e
           x-celigo-ui-override: 'Required by the connection form for oauth (subForms/httpOAuth.js: required true, iClient filter provider custom_oauth2, or googleserviceaccount / azureserviceprincipal for the GCS and ADLS Gen2 variants) and for awsIam (subForms/httpAwsIam.js: required true, filter provider awsIam). For oauth the API creates the connection without it and the authorization is completed afterward; for awsiam the API also rejects its absence (see the if/then rule on this schema).'
@@ -10078,7 +10094,20 @@ components:
             - |-
               The iClient must belong to the same account as the connection — an iClient id from
               another account fails with 422 invalid_ref "The referenced IClient must belong to the
-              same user."
+              same user." The one exception is the iClient a pre-built OAuth HTTP connector
+              pre-configures (Celigo's published app — the Shopify Public App's, for one): the
+              connection saves with that id from the connecting account even though
+              `GET /v1/iclients/{_id}` on it is 404 there, so do not refuse a `public` Shopify
+              connection on this rule.
+            - |-
+              On a Shopify connection keep `settings.appType` and `_iClientId` in step the way the
+              form does — `public` with the connector's published iClient, `custom` with an
+              account-owned iClient: the API saves either value of `settings.appType` beside either
+              iClient (and any other string under `settings.appType`) — nothing server-side checks
+              the pair, so the form's rule is the only guard. On an update never drop `_iClientId` from
+              an `auth.type` `oauth` connection: 422 invalid_field_update "Removing _iClientId is
+              not allowed for oauth connections due to security reasons." — switch it to another
+              iClient instead.
         _httpConnectorId:
           type: string
           format: objectId

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@celigo/api-specs",
-  "version": "0.2.186",
+  "version": "0.2.188",
   "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": "5527b75e",
+		"iasCommit": "a6978822",
 		"generatedAt": "2026-10-23"
 	},
 	"roots": {