Ecwid by Lightspeed vs Saleor API + MCP

Ecwid by Lightspeed

The REST API has 40 access scopes, a published limit of 600 requests a minute per token with Retry-After on a 429, field selection through responseFields, and Markdown docs with an llms.txt index. Tokens never expire, there is no test mode or idempotency key, API access needs a paid plan, and carts are built only in the browser.

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.

Ecwid by Lightspeed

1. Send the token as Authorization: Bearer to https://app.ecwid.com/api/v3/{storeId}. Tokens in the query string stopped working in March 2025
2. Use the secret token server-side only. The public token reads enabled products and places orders that are not marked paid
3. Add responseFields, for example total,items(id,name,price), to keep responses small, and page with offset and limit (maximum 100)
4. Stay under 600 requests a minute per token and wait the Retry-After seconds on a 429. Repeated calls with a bad token get the token and IP blocked for longer
5. Work in a separate test store. There is no test mode, and POST /orders writes a real order with no idempotency key
6. After changing an app's scopes, uninstall and reinstall it, then replace the stored tokens. The old ones stop working

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