Adobe Commerce (Magento) vs Saleor API + MCP

Adobe Commerce (Magento)

Public Swagger files cover 510 REST operations for the cloud service, the GraphQL schema carries cart, checkout and order mutations, and the cloud service authenticates by OAuth 2 through Adobe IMS. No request rate limit or idempotency key was found in the API documentation, Adobe publishes no MCP server for Commerce, and a licence starts with a sales order.

Saleor API + MCP

One GraphQL schema with 78 typed error-code enums and 464 marked deprecations. The MCP server can't create checkouts or orders.

Adobe Commerce (Magento)

1. Ask which deployment the store is. The cloud service answers at https://<server>.api.commerce.adobe.com/<tenant-id>/ with no /rest prefix, and other stores at https://<host>/rest/<store-view-code>/
2. On the cloud service, request an IMS token with the commerce.accs scope and send the Store header to pick the store view
3. On a 2.4 store, sign requests with all four integration credentials by OAuth 1.0a. A bare integration token is refused unless the merchant has switched that on
4. Add ?fields= to REST calls and set searchCriteria[pageSize]. Stores with input limits on cap a page at 300 items
5. Don't retry placeOrder or a POST blindly. Read the cart or order back first, because no idempotency key was found

Saleor API + MCP

1. Pass the channel slug on product and checkout queries. Prices and availability are per channel
2. Send X-Saleor-API-URL and X-Saleor-Auth-Token on every MCP request, with a token holding MANAGE_PRODUCTS and MANAGE_ORDERS
3. Read the errors array in every mutation payload. A 200 response can still carry a CheckoutErrorCode
4. Keep queries under the 50,000 complexity cap and 100 items a page, and send at most 4 mutations per request
5. The 3.24 changelog removes the old dummy payment plugins, so test checkouts should use a payment app