Svelte Commerce × Saleor
Svelte Commerce on Saleor
The Saleor connector talks to Saleor’s GraphQL API from a single environment variable. Its guide describes cart, checkout and sign-in as Saleor-native, but the coverage script counts none of the three as wired, so for now it cannot sell.
- 28/43 services wired
- @misiki/saleor-connector 1.0.3
- Cart not yet wired
- Checkout not yet wired
- Sign-in (auth) not yet wired
What works on Saleor today
Cannot sell yet. The coverage script counts cart, checkout and sign-in as not wired — along with orders, categories, coupons, search, addresses, pages and payment methods — and CONNECTORS.md says this connector predates the current wiring pass. Its own guide adds that the card gateways throw “not implemented”.
Cart
Not yet wired, by the coverage script’s measure.
Checkout
Not yet wired, by the coverage script’s measure.
Sign-in (auth)
Not yet wired, by the coverage script’s measure.
Known gaps: auth, cart, checkout, order, category, coupon, search, address, user, page, payment-method — each is explained under Limitations below.
28 of 43 services wired, read from CONNECTORS.md on , where the package version is recorded too; npm may carry a newer patch. Coverage is traced by a script in the Svelte Commerce repository: a service counts as wired only if it transitively issues an HTTP request, or delegates to one that does. It is not hand-asserted. Some services are Litekart-native concepts with no equivalent elsewhere (reels, deals, chat, gallery, popularity, demo-request, feedback, plugins, banner). They stay documented placeholders on every connector and are excluded from known gaps.
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.
Clone it, choose the connector, point it at Saleor
# 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 devThe guide removes only @misiki/litekart-connector. A fresh clone’s package.json also lists @misiki/vendure-connector, and with two connectors installed and neither of them Litekart’s, the build stops and asks for PUBLIC_CONNECTOR — so this removes both.
Environment variables
| Variable | Required | What it does |
|---|---|---|
PUBLIC_SALEOR_API_URL | Yes | The full Saleor GraphQL endpoint, such as https://your-store.saleor.cloud/graphql/ — the endpoint, not just the host. |
PUBLIC_CONNECTOR | No | Only when more than one connector is installed: @misiki/saleor-connector names the one this build runs on. |
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
isPhoneMandatorytofalse. - 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_URLdirectly.
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
- 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.
- Orders: not wired.
- Categories: not wired.
- Coupons: not wired.
- Search: not wired.
- Saved addresses: not wired.
- User accounts: not wired.
- CMS pages: not wired — CMS-style pages show the connector’s placeholder content.
- Payment-method listing: not wired.
- The card gateways — Razorpay, Stripe, PhonePe, PayPal, Cashfree, Affirm — throw “not implemented” in this connector.
- No OTP sign-in:
getOtpthrows. - Homepage sections other than the live product list come from the active theme’s static content — the standing rule for themes.
- 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
| When you see | What to do |
|---|---|
| Boot fails with “PUBLIC_SALEOR_API_URL is set, but it configures a different backend than the one this build runs on” | The variable is set while a different connector is installed. Install @misiki/saleor-connector, or remove the variable if you meant to run another backend. With more than one connector installed, set PUBLIC_CONNECTOR='@misiki/saleor-connector'. |
| The build stops with “Several commerce connectors are installed … Set PUBLIC_CONNECTOR to pick one” | More than one @misiki/*-connector is in package.json and none is Litekart’s. Uninstall the ones you do not run — a fresh clone also lists @misiki/vendure-connector — or set PUBLIC_CONNECTOR='@misiki/saleor-connector'. |
[saleor] no native implementation for get /api/... in the console | The connector’s REST guard caught a path inherited from Litekart and answered it empty instead of requesting it. Each path is reported once. Harmless if Saleor has no such feature; if it has one, implement it in the connector’s matching service. |
http proxy error: api/... ECONNREFUSED in dev | A Litekart REST path was requested from outside the connector, so neither its guard nor blockRestFallbacks saw it. Vite proxies /api to PUBLIC_LITEKART_API_URL, or to localhost:7000. |
| The store is called “Test”, or shows the wrong branding | Set identity overrides — name, logo, favicon, currencyCode and the rest — in the default export of kitcommerce.config.ts. |
| Sign-in or cart works in dev but not when deployed | Almost always CORS: allow the deployed storefront’s origin on the Saleor API. |
Before you rely on it
The one caveat that matters
Read this before choosing
Every connector was written by reading its platform’s authoritative source — an OpenAPI spec, a RAML file, a router registration or the controller source — rather than by running against a store. No connector has been exercised against a live production instance of its platform.
Offer a sandbox or a correctionFAQ
Questions about Svelte Commerce on Saleor
Can I sell on Saleor with Svelte Commerce today?
Not yet. The coverage script counts cart, checkout and sign-in as not wired, CONNECTORS.md says the Saleor connector predates the current wiring pass, and its own guide says the card gateways throw “not implemented”.
Why does the guide describe a working checkout when the table says it is not wired?
The guide describes what the connector calls; the coverage script counts a service only when it reaches the connector’s own HTTP layer, and does not count cart, checkout or auth. CONNECTORS.md lists Saleor as a next candidate for the source-verification sweep that would settle it.
Which Saleor settings does Svelte Commerce need?
Email confirmation for registration turned off, isPhoneMandatory set to false, unpaid orders allowed in both the order settings and the channel settings, and the storefront’s origin allowed in CORS.
What goes in PUBLIC_SALEOR_API_URL?
The full GraphQL endpoint, such as https://your-store.saleor.cloud/graphql/ — not only the host. It is the one variable the Saleor connector needs.
Sources
This page summarises SALEOR.md in the Svelte Commerce repository and the Saleor connector’s source, read on , and the coverage in CONNECTORS.md, read on . Where they disagree with this page, they are right and this page is out of date. Saleor is a trademark of its owner, named here only to describe compatibility; no endorsement or affiliation is implied — see trademarks.
Read the whole guide
The storefront is the same on every backend; the connector is what changes. SALEOR.md has the Saleor setup in full, beside the connector’s source.