Svelte Commerce on Saleor

What works on Saleor today

Known gaps: auth, cart, checkout, order, category, coupon, search, address, user, page, payment-method

28 of 43 services wired, read from CONNECTORS.md on 21 September 2026; npm may carry a newer patch. How coverage is measured.

What the connector calls on Saleor

The connector calls Saleor’s GraphQL API at the single endpoint given in PUBLIC_SALEOR_API_URL, through the graphql-request client, with every catalogue query scoped to the channel default-channel.

The connector sends no store credential, only the endpoint URL; when localStorage holds a saleor_token, each GraphQL request carries it as authorization: Bearer <token>, and Svelte Commerce’s coverage script does not count shopper sign-in as wired.

Saleor rules the connector follows

• The channel is fixed in the source as default-channel on every product and collection query, so a Saleor store must have a channel with that slug.
• The product and collection lists send first with no cursor, so they return the first 20 records whatever page is asked for, and the total comes from the connection’s totalCount.
• The product queries request only thumbnail for images and pricing.priceRange.start.gross for money, so a product carries one image, its price and mrp are the same figure, and stock is reported as 0.
• Saleor returns rich-text descriptions as JSON blocks, and the connector joins the data.text of each block and strips HTML tags to make a plain-text description.
• When a GraphQL error mentions an expired or invalid token, the connector sends one mutation TokenRefresh with the saleor_refresh_token from localStorage and retries; if that fails it removes both tokens and clears the me and connect.sid cookies.

Read from the source of misiki-in/saleor-connector at commit 87c3f2e of 25 August 2026. Where the code has changed since, the code is right.

Quick start

From nothing to a Svelte Commerce storefront reading Saleor. You need Node.js and a Saleor to point it at; the storefront holds no data of its own.

# 1 — get the storefront
git clone https://github.com/itswadesh/svelte-commerce
cd svelte-commerce

# 2 — one connector at a time: remove the two the storefront ships with, add this one
npm uninstall @misiki/litekart-connector @misiki/vendure-connector
npm i @misiki/saleor-connector

# 3 — point it at your Saleor GraphQL endpoint
echo PUBLIC_SALEOR_API_URL=https://your-store.saleor.cloud/graphql/ >> .env

# 4 — run it
npm run dev

Switching works the same way on every backend: what all 26 share, from one connector at a time to store identity.

Environment variables

The Litekart trio is not used in Saleor mode; /health reports ready when PUBLIC_SALEOR_API_URL is set and the Saleor connector is active.

Every variable here begins PUBLIC_, and SvelteKit sends PUBLIC_ variables to the browser: treat each value you set as published.

What to set up on Saleor

• Turn off email confirmation for user registration.
• Set isPhoneMandatory to false.
• Allow unpaid orders in the order settings.
• Allow unpaid orders in the channel settings too.
• Allow the storefront’s origin in CORS: the browser calls PUBLIC_SALEOR_API_URL directly.

How the integration works

At boot, init in both hooks (through src/lib/core/connectors/init.ts) writes PUBLIC_SALEOR_API_URL onto the connector’s BaseService.SALEOR_API_URL. The server hook covers server rendering; the client hook covers the browser, which must reach the public Saleor URL in production.

By the guide’s account, cart, shipping rates, payment-method listing and cash-on-delivery checkout are Saleor-native GraphQL; categories map to Saleor categories; and the profile page delegates to Saleor’s me and accountUpdate. checkoutComplete requires an email on the checkout, so the static store config defaults isEmailMandatory to true.

Store identity, menus and plugin toggles are static — default-store.json under the default export of kitcommerce.config.ts. CMS pages are the connector’s own static placeholders. Any other Litekart REST path is never requested: list reads resolve empty, single-record reads and writes throw. From connector 1.0.4 the store lookup it once inherited from Litekart is answered by the connector itself.

The coverage script and the guide disagree. The script counts a service as wired only if it reaches the connector’s own HTTP layer, and it does not count auth, cart, checkout, order, category, coupon, search, address, user, page or payment-method. CONNECTORS.md names Medusa and Saleor as the next candidates for the source-verification sweep.

Limitations on Saleor

• Sign-in (auth): not wired — the coverage script does not count it, though the guide describes email sign-in as native GraphQL.
• Cart: not wired — the coverage script does not count it, though the guide describes the cart as Saleor-native.
• Checkout: not wired — the coverage script does not count it, though the guide describes cash-on-delivery checkout as Saleor-native.
• CMS pages: not wired — CMS-style pages show the connector’s placeholder content.
• The card gateways — Razorpay, Stripe, PhonePe, PayPal, Cashfree, Affirm — throw “not implemented” in this connector.
• No OTP sign-in: getOtp throws.
• If the Saleor catalogue has no matching products, product grids render their empty or loading states; the pages still work.
• The Conversational Shopping assistant is Litekart-only; its widget stays hidden in Saleor mode without firing requests.

Troubleshooting Saleor

Before you rely on it