npm - @celigo/api-specs - Versions diffs - 0.2.188 → 0.2.189 - Mend

@celigo/api-specs 0.2.188 → 0.2.189

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (7) hide show

package/dist/api.yml CHANGED Viewed

@@ -7160,19 +7160,25 @@ components:
             - |-
               The prebuilt Amazon connection forms collect the API type, selling region and marketplace
               and save an OAuth 2.0 authorization-code connection (`http.auth.type` `oauth`,
-              `http.auth.oauth.grantType` `authorizecode`, `useIClientFields` false) whose authorization
-              URI is the Seller Central or Vendor Central `/apps/authorize/consent` page — Amazon's
-              public-application consent, granted by the selling partner to Celigo's registered
-              Selling Partner API application. Celigo's Seller Central documentation states the customer
-              need not register as an Amazon developer (article 360060827012); the Vendor Central form
-              carries no developer credentials either.
+              `http.auth.oauth.grantType` `authorizecode`) whose authorization URI is the Seller Central
+              or Vendor Central `/apps/authorize/consent` page: Amazon's public-application consent,
+              granted by the selling partner to Celigo's registered Selling Partner API application. For
+              `vendor_central` the create request omits `http._iClientId` — the customer never sends
+              one — and the connector writes Celigo's published Global iClient onto the saved
+              connection as `http._iClientId` (`useIClientFields` true), so the saved document does
+              carry an iClient id, Celigo's. Celigo's Seller
+              Central documentation states the customer need not register as an Amazon developer
+              (article 360060827012); the Vendor Central form carries no developer credentials either.
             - |-
               The prebuilt forms collect no Amazon developer application id, client secret, AWS
-              credentials or iClient — the Vendor Central form has no iClient field, and the Seller
-              Central form sets `http._iClientId` only for its legacy `Amazon-MWS` choice — so creating
-              one of these connections asks the customer for a Seller Central or Vendor Central account
-              for the chosen region and marketplace and a user who can complete Amazon's consent screen,
-              nothing more. A customer who must run on their OWN developer registration builds a
+              credentials or customer-owned iClient (the Seller Central form offers an iClient field
+              only for its legacy `Amazon-MWS` choice), so creating one of these connections asks the
+              customer for a Seller Central or Vendor Central account for the chosen region and
+              marketplace and a user who can complete Amazon's consent screen — for Vendor Central, a
+              user holding the Manage Integrations (EDI/API) permission for the vendor group the
+              integration should reach. Amazon requires public applications to be re-authorized every
+              365 days; the customer re-runs the authorization from the existing connection and nothing
+              else changes. A customer who must run on their OWN developer registration builds a
               token-based or OAuth 2.0 universal HTTP connection to the Selling Partner API base URI
               instead (articles 6204088366363 and the OAuth 2.0 universal connector) and takes on
               Amazon's developer agreements themselves.

package/dist/connection.yml CHANGED Viewed

@@ -5779,19 +5779,25 @@ components:
             - |-
               The prebuilt Amazon connection forms collect the API type, selling region and marketplace
               and save an OAuth 2.0 authorization-code connection (`http.auth.type` `oauth`,
-              `http.auth.oauth.grantType` `authorizecode`, `useIClientFields` false) whose authorization
-              URI is the Seller Central or Vendor Central `/apps/authorize/consent` page — Amazon's
-              public-application consent, granted by the selling partner to Celigo's registered
-              Selling Partner API application. Celigo's Seller Central documentation states the customer
-              need not register as an Amazon developer (article 360060827012); the Vendor Central form
-              carries no developer credentials either.
+              `http.auth.oauth.grantType` `authorizecode`) whose authorization URI is the Seller Central
+              or Vendor Central `/apps/authorize/consent` page: Amazon's public-application consent,
+              granted by the selling partner to Celigo's registered Selling Partner API application. For
+              `vendor_central` the create request omits `http._iClientId` — the customer never sends
+              one — and the connector writes Celigo's published Global iClient onto the saved
+              connection as `http._iClientId` (`useIClientFields` true), so the saved document does
+              carry an iClient id, Celigo's. Celigo's Seller
+              Central documentation states the customer need not register as an Amazon developer
+              (article 360060827012); the Vendor Central form carries no developer credentials either.
             - |-
               The prebuilt forms collect no Amazon developer application id, client secret, AWS
-              credentials or iClient — the Vendor Central form has no iClient field, and the Seller
-              Central form sets `http._iClientId` only for its legacy `Amazon-MWS` choice — so creating
-              one of these connections asks the customer for a Seller Central or Vendor Central account
-              for the chosen region and marketplace and a user who can complete Amazon's consent screen,
-              nothing more. A customer who must run on their OWN developer registration builds a
+              credentials or customer-owned iClient (the Seller Central form offers an iClient field
+              only for its legacy `Amazon-MWS` choice), so creating one of these connections asks the
+              customer for a Seller Central or Vendor Central account for the chosen region and
+              marketplace and a user who can complete Amazon's consent screen — for Vendor Central, a
+              user holding the Manage Integrations (EDI/API) permission for the vendor group the
+              integration should reach. Amazon requires public applications to be re-authorized every
+              365 days; the customer re-runs the authorization from the existing connection and nothing
+              else changes. A customer who must run on their OWN developer registration builds a
               token-based or OAuth 2.0 universal HTTP connection to the Selling Partner API base URI
               instead (articles 6204088366363 and the OAuth 2.0 universal connector) and takes on
               Amazon's developer agreements themselves.

package/dist/enduser.yml CHANGED Viewed

@@ -3830,19 +3830,25 @@ components:
             - |-
               The prebuilt Amazon connection forms collect the API type, selling region and marketplace
               and save an OAuth 2.0 authorization-code connection (`http.auth.type` `oauth`,
-              `http.auth.oauth.grantType` `authorizecode`, `useIClientFields` false) whose authorization
-              URI is the Seller Central or Vendor Central `/apps/authorize/consent` page — Amazon's
-              public-application consent, granted by the selling partner to Celigo's registered
-              Selling Partner API application. Celigo's Seller Central documentation states the customer
-              need not register as an Amazon developer (article 360060827012); the Vendor Central form
-              carries no developer credentials either.
+              `http.auth.oauth.grantType` `authorizecode`) whose authorization URI is the Seller Central
+              or Vendor Central `/apps/authorize/consent` page: Amazon's public-application consent,
+              granted by the selling partner to Celigo's registered Selling Partner API application. For
+              `vendor_central` the create request omits `http._iClientId` — the customer never sends
+              one — and the connector writes Celigo's published Global iClient onto the saved
+              connection as `http._iClientId` (`useIClientFields` true), so the saved document does
+              carry an iClient id, Celigo's. Celigo's Seller
+              Central documentation states the customer need not register as an Amazon developer
+              (article 360060827012); the Vendor Central form carries no developer credentials either.
             - |-
               The prebuilt forms collect no Amazon developer application id, client secret, AWS
-              credentials or iClient — the Vendor Central form has no iClient field, and the Seller
-              Central form sets `http._iClientId` only for its legacy `Amazon-MWS` choice — so creating
-              one of these connections asks the customer for a Seller Central or Vendor Central account
-              for the chosen region and marketplace and a user who can complete Amazon's consent screen,
-              nothing more. A customer who must run on their OWN developer registration builds a
+              credentials or customer-owned iClient (the Seller Central form offers an iClient field
+              only for its legacy `Amazon-MWS` choice), so creating one of these connections asks the
+              customer for a Seller Central or Vendor Central account for the chosen region and
+              marketplace and a user who can complete Amazon's consent screen — for Vendor Central, a
+              user holding the Manage Integrations (EDI/API) permission for the vendor group the
+              integration should reach. Amazon requires public applications to be re-authorized every
+              365 days; the customer re-runs the authorization from the existing connection and nothing
+              else changes. A customer who must run on their OWN developer registration builds a
               token-based or OAuth 2.0 universal HTTP connection to the Selling Partner API base URI
               instead (articles 6204088366363 and the OAuth 2.0 universal connector) and takes on
               Amazon's developer agreements themselves.

package/dist/mcp-server.yml CHANGED Viewed

@@ -5666,19 +5666,25 @@ components:
             - |-
               The prebuilt Amazon connection forms collect the API type, selling region and marketplace
               and save an OAuth 2.0 authorization-code connection (`http.auth.type` `oauth`,
-              `http.auth.oauth.grantType` `authorizecode`, `useIClientFields` false) whose authorization
-              URI is the Seller Central or Vendor Central `/apps/authorize/consent` page — Amazon's
-              public-application consent, granted by the selling partner to Celigo's registered
-              Selling Partner API application. Celigo's Seller Central documentation states the customer
-              need not register as an Amazon developer (article 360060827012); the Vendor Central form
-              carries no developer credentials either.
+              `http.auth.oauth.grantType` `authorizecode`) whose authorization URI is the Seller Central
+              or Vendor Central `/apps/authorize/consent` page: Amazon's public-application consent,
+              granted by the selling partner to Celigo's registered Selling Partner API application. For
+              `vendor_central` the create request omits `http._iClientId` — the customer never sends
+              one — and the connector writes Celigo's published Global iClient onto the saved
+              connection as `http._iClientId` (`useIClientFields` true), so the saved document does
+              carry an iClient id, Celigo's. Celigo's Seller
+              Central documentation states the customer need not register as an Amazon developer
+              (article 360060827012); the Vendor Central form carries no developer credentials either.
             - |-
               The prebuilt forms collect no Amazon developer application id, client secret, AWS
-              credentials or iClient — the Vendor Central form has no iClient field, and the Seller
-              Central form sets `http._iClientId` only for its legacy `Amazon-MWS` choice — so creating
-              one of these connections asks the customer for a Seller Central or Vendor Central account
-              for the chosen region and marketplace and a user who can complete Amazon's consent screen,
-              nothing more. A customer who must run on their OWN developer registration builds a
+              credentials or customer-owned iClient (the Seller Central form offers an iClient field
+              only for its legacy `Amazon-MWS` choice), so creating one of these connections asks the
+              customer for a Seller Central or Vendor Central account for the chosen region and
+              marketplace and a user who can complete Amazon's consent screen — for Vendor Central, a
+              user holding the Manage Integrations (EDI/API) permission for the vendor group the
+              integration should reach. Amazon requires public applications to be re-authorized every
+              365 days; the customer re-runs the authorization from the existing connection and nothing
+              else changes. A customer who must run on their OWN developer registration builds a
               token-based or OAuth 2.0 universal HTTP connection to the Selling Partner API base URI
               instead (articles 6204088366363 and the OAuth 2.0 universal connector) and takes on
               Amazon's developer agreements themselves.

package/dist/tool.yml CHANGED Viewed

@@ -9200,19 +9200,25 @@ components:
             - |-
               The prebuilt Amazon connection forms collect the API type, selling region and marketplace
               and save an OAuth 2.0 authorization-code connection (`http.auth.type` `oauth`,
-              `http.auth.oauth.grantType` `authorizecode`, `useIClientFields` false) whose authorization
-              URI is the Seller Central or Vendor Central `/apps/authorize/consent` page — Amazon's
-              public-application consent, granted by the selling partner to Celigo's registered
-              Selling Partner API application. Celigo's Seller Central documentation states the customer
-              need not register as an Amazon developer (article 360060827012); the Vendor Central form
-              carries no developer credentials either.
+              `http.auth.oauth.grantType` `authorizecode`) whose authorization URI is the Seller Central
+              or Vendor Central `/apps/authorize/consent` page: Amazon's public-application consent,
+              granted by the selling partner to Celigo's registered Selling Partner API application. For
+              `vendor_central` the create request omits `http._iClientId` — the customer never sends
+              one — and the connector writes Celigo's published Global iClient onto the saved
+              connection as `http._iClientId` (`useIClientFields` true), so the saved document does
+              carry an iClient id, Celigo's. Celigo's Seller
+              Central documentation states the customer need not register as an Amazon developer
+              (article 360060827012); the Vendor Central form carries no developer credentials either.
             - |-
               The prebuilt forms collect no Amazon developer application id, client secret, AWS
-              credentials or iClient — the Vendor Central form has no iClient field, and the Seller
-              Central form sets `http._iClientId` only for its legacy `Amazon-MWS` choice — so creating
-              one of these connections asks the customer for a Seller Central or Vendor Central account
-              for the chosen region and marketplace and a user who can complete Amazon's consent screen,
-              nothing more. A customer who must run on their OWN developer registration builds a
+              credentials or customer-owned iClient (the Seller Central form offers an iClient field
+              only for its legacy `Amazon-MWS` choice), so creating one of these connections asks the
+              customer for a Seller Central or Vendor Central account for the chosen region and
+              marketplace and a user who can complete Amazon's consent screen — for Vendor Central, a
+              user holding the Manage Integrations (EDI/API) permission for the vendor group the
+              integration should reach. Amazon requires public applications to be re-authorized every
+              365 days; the customer re-runs the authorization from the existing connection and nothing
+              else changes. A customer who must run on their OWN developer registration builds a
               token-based or OAuth 2.0 universal HTTP connection to the Selling Partner API base URI
               instead (articles 6204088366363 and the OAuth 2.0 universal connector) and takes on
               Amazon's developer agreements themselves.

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@celigo/api-specs",
-  "version": "0.2.188",
+  "version": "0.2.189",
   "private": false,
   "description": "Public OpenAPI bundles (dist/) and the celigo-cli lint schema pack (schemas.json).",
   "keywords": [

package/schemas.json CHANGED Viewed

@@ -1,7 +1,7 @@
 {
 	"provenance": {
 		"repo": "celigo/integrator-api-specs",
-		"iasCommit": "a6978822",
+		"iasCommit": "d34fe6f2",
 		"generatedAt": "2026-10-23"
 	},
 	"roots": {