Saleor is one of four backends whose environment wiring ships in the repo, so getting a storefront running against it is a three-step job. It is also one of two connectors we are openly less confident about, and it is worth saying why up front.
Setup
$ npm uninstall @misiki/litekart-connector
$ npm i @misiki/saleor-connector// kitcommerce.config.ts
export * as services from './src/lib/core/connectors/saleor'# .env
PUBLIC_SALEOR_API_URL=https://your-store.saleor.cloud/graphql/init.ts picks that variable up at boot and writes BaseService.SALEOR_API_URL. It also fails loudly if you set it while a different connector is active in kitcommerce.config.ts — a guard that exists because silently writing one connector's statics onto another's BaseService produces symptoms that are miserable to trace.
What is wired
Auth, cart, checkout, order, category, coupon, search, address, user, page and payment-method. That is the whole path a shopper walks: browse, filter, add, apply a code, check out, look at the order afterwards.
Like Vendure and Medusa, Saleor goes through an override module so store and page metadata resolve from static config instead of hitting Litekart REST endpoints that are not there.
The honest part
Saleor and Medusa predate the current source-verification sweep. The other connectors were each written by reading the platform's authoritative contract — the OpenAPI document, the GraphQL schema, or the published spec — and checked field by field against it. Saleor and Medusa were written earlier, cover the core path, and have not been through that same pass. They are the next two candidates for it.
That is a different statement from "they are broken". They work. But if you are choosing a backend partly on connector confidence, Vendure is the one with both the highest coverage and the completed verification pass.
Per-service detail and troubleshooting: docs/SALEOR.md. The scoring methodology and every platform's open questions are in the capability matrix.