Which backends Svelte Commerce speaks to, and how completely
Svelte Commerce talks to a backend through a connector: a package that maps one platform’s API onto a shared 43-service surface. Nothing in the storefront imports a connector by name, so installing a different package runs the same storefront on a different backend.
- 26 connectors
- 43 services in the surface
- 2 at 39/43
- 0 hand-asserted numbers
Coverage, measured
Coverage is not claimed, it is traced: a script follows each connector’s own request helpers and counts a service as wired only if it genuinely reaches the HTTP layer. Sort order is coverage, highest first.
- Wired — issues a real request
- No endpoint on the platform — throws rather than faking a session
- Not yet wired
Read from svelte-commerce/docs/CONNECTORS.md on . 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.
| Platform | Coverage | Cart | Checkout | Auth | Known gaps |
|---|---|---|---|---|---|
| Litekart ↗ | wired | wired | wired | reference implementation | |
| Vendure ↗ | wired | wired | wired | none | |
| Medusa ↗ | not yet wired | wired | not yet wired | auth, cart, product, category, search, address, user, payment-method | |
| Broadleaf ↗ | wired | wired | wired | none | |
| Saleor ↗ | not yet wired | not yet wired | not yet wired | auth, cart, checkout, order, category, coupon, search, address, user, page, payment-method | |
| Shopware ↗ | wired | wired | wired | coupon | |
| Virto Commerce ↗ | wired | wired | wired | none | |
| WooCommerce ↗ | wired | wired | no endpoint on the platform | auth (no core endpoint), wishlist | |
| Magento ↗ | wired | wired | wired | review, wishlist | |
| Spree ↗ | wired | wired | wired | review | |
| X-Cart ↗ | wired | wired | wired | vendor | |
| Shopify ↗ | wired | wired | wired | review, wishlist, vendor, page, profile, country | |
| EverShop ↗ | wired | wired | wired | review, wishlist, vendor | |
| Spryker ↗ | wired | wired | wired | coupon | |
| nopCommerce ↗ | wired | wired | wired | coupon, currency | |
| PrestaShop ↗ | wired | wired | no endpoint on the platform | auth, review, wishlist, payment-method | |
| Sylius ↗ | wired | wired | wired | wishlist, vendor, page | |
| Swell ↗ | wired | wired | wired | review, wishlist, vendor, state | |
| Bagisto ↗ | wired | wired | wired | coupon, page, payment-method, vendor | |
| commercetools ↗ | wired | wired | wired | country, currency, page, vendor | |
| OroCommerce ↗ | wired | wired | wired | review, wishlist, currency, vendor | |
| Sharetribe ↗ | not yet wired | wired | wired | cart, coupon, address, country, state, wishlist | |
| CS-Cart ↗ | wired | wired | no endpoint on the platform | auth, address, country, state, currency, coupon, wishlist | |
| Shuup ↗ | wired | wired | wired | coupon, review, page, country, state, wishlist | |
| Django Oscar ↗ | wired | wired | wired | coupon, review, search, page, payment-method, currency, state, wishlist, vendor | |
| OpenCart ↗ | wired | wired | no endpoint on the platform | catalogue, search, auth, address, user, profile, coupon, page, wishlist, vendor | |
| GoCommerce | — | wired | wired | needs the identity module | early connector, 0.16.0 — not measured by the coverage script; sign-in needs GoCommerce’s identity module |
How to read it
A low score is often correct
OpenCart core ships exactly ten API controllers and no product, category or search controller at all. Its 9/43 is the honest ceiling for that API, not a to-do list.
“No endpoint” is not a gap
Where a platform has no real customer-auth endpoint, auth throws rather than minting a session. A stub that logs anyone in for any password is an auth bypass, not a placeholder.
Some services count for nobody
Reels, deals, chat, gallery, popularity and a few others are Litekart-native concepts with no equivalent elsewhere. They stay documented placeholders and are excluded from the gaps column.
The one caveat that matters
Read this before choosing
Every connector was written by reading its platform’s authoritative source — the OpenAPI spec, the RAML, the router registration, or the controller source. No endpoint was guessed, and where a route could not be verified it was left an explicit placeholder rather than shipped as a plausible path that 404s in a merchant’s store.
But reading a spec is not running against a real store. None of these connectors has been exercised against a live production instance of its platform. That is the single biggest gap in this table, and it is the thing platform maintainers can help with that we cannot do alone.
Offer a sandbox or a correctionWhat every backend shares
The storefront is the same on all 26, so switching, store identity, a few limits and the common errors are the same too. Each backend’s own page covers only what differs.
- Installing the package is the whole switch
vite.config.tsresolves whichever@misiki/*-connectoris installed, andsrc/lib/core/connectors/init.tshands it everyPUBLIC_<BACKEND>_*variable that is set, camel-cased, at boot: in the server hook for server rendering and in the client hook for the browser, which must reach the same URL in production. - One connector at a timeA fresh clone’s
package.jsonlists@misiki/litekart-connectorand@misiki/vendure-connector. With two connectors installed and neither of them Litekart’s, the build stops and asks forPUBLIC_CONNECTOR, so each backend’s quick start removes both before adding its own. - Store identity is staticWith no Litekart API behind the storefront, the name, logo, currency, menus, plugin toggles and theme colours come from
src/lib/core/connectors/default-store.json, merged under the default export ofkitcommerce.config.ts. Until you override it, the store is called “Test”. Any Litekart REST path a connector still inherits is answered from that local data, or resolved empty, rather than requested. - Cross-origin requestsIn production the browser calls the backend’s API URL directly, not only the server, so the backend must accept requests from the storefront’s origin (CORS).
Limits on every backend but Litekart
- Pages that depend on a service that is not wired render their empty state rather than failing.
- Homepage sections other than the live product list come from the active theme’s static content, the standing rule for themes.
- The Conversational Shopping assistant is Litekart-only; its widget stays hidden when another connector is active.
Errors any switch can meet
| When you see | What to do |
|---|---|
| Boot fails with “the <backend> connector is active but PUBLIC_<BACKEND>_API_URL is not set” | Add that variable to .env. A production Node build and Docker read PUBLIC_* from the process environment rather than .env, so set it on your deploy platform too. |
| 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, or set PUBLIC_CONNECTOR to the package you do. |
| Boot fails with “PUBLIC_…_API_URL is set, but it configures a different backend than the one this build runs on” | Another backend’s variable is still set, usually left over from the one you switched from. Remove it, or install that backend’s connector. PUBLIC_LITEKART_API_URL is exempt: it only points the dev proxy. |
| The store is called “Test”, or shows the wrong name and logo | Set name, logo, currencyCode and the rest in the default export of kitcommerce.config.ts; default-store.json lists every field. |
[<backend>] 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 the platform has no such feature; if it has one, the fix belongs in the connector’s matching service. |
http proxy error: api/... ECONNREFUSED in dev | A Litekart REST path was requested from outside the connector, so its guard never saw it. Vite proxies /api to PUBLIC_LITEKART_API_URL, or to localhost:7000. |
The build fails on @misiki/litekart-connector | @misiki/kitcommerce-core declares it as a peer, and vite.config.ts redirects that specifier to whichever connector is installed. Make sure exactly one @misiki/*-connector is listed in package.json. |
FAQ
Questions about backends
How many backends does Svelte Commerce support?
26 connectors exist today, covering Litekart, Vendure, Medusa, Broadleaf, Saleor, Shopware, Virto Commerce, WooCommerce, Magento, Spree, X-Cart, EverShop, Spryker, nopCommerce, PrestaShop, Sylius, Swell, Bagisto, commercetools, OroCommerce, Sharetribe, CS-Cart, Shuup, Shopify, Django Oscar and OpenCart. They differ a great deal in how complete they are, which is what the coverage column on this page is for.
Which connectors are the most complete?
Litekart and Vendure, both at 39 of 43 services, with cart, checkout and auth all wired. Litekart is the reference implementation and Vendure’s GraphQL Shop API covers essentially the whole surface.
Is the coverage number reliable?
It is measured rather than asserted. A script traces which service methods transitively reach the HTTP layer, following each connector’s own request helpers, and a service counts as wired only if it genuinely issues a request or delegates to one that does. What the number does not tell you is whether the connector has been run against a live store, because none of them has.
Can I use Svelte Commerce with GoCommerce?
Yes, through an early connector: @misiki/gocommerce-connector 0.16.0, on npm, covers catalogue, cart, cash-on-delivery checkout and order lookup; shopper sign-in, the address book and order history need GoCommerce’s identity module. It sits at the bottom of this table, outside the 26, because the script behind the coverage column has not measured it; the connector status page describes what it does instead.
What if my platform is not listed?
Then there is no adapter for it yet. A connector is a TypeScript package mapping one platform’s API onto the shared service surface, so adding one does not require changing the storefront. The existing 26 are the pattern to follow.
Pick a backend, or help fix one
The storefront is the same either way. The connector is what changes.