Svelte Commerce × Medusa
Svelte Commerce on Medusa
The Medusa connector reaches Medusa’s Store API with a publishable key and a region. Its guide describes cart, checkout and sign-in as Medusa-native, but the coverage script does not count cart or sign-in as wired — and until that is settled, it cannot sell.
- 31/43 services wired
- @misiki/medusa-connector 2.1.5
- Cart not yet wired
- Checkout wired
- Sign-in (auth) not yet wired
What works on Medusa today
Cannot sell yet. The coverage script counts cart and sign-in — and products, categories and search — as not wired, and CONNECTORS.md says this connector predates the current wiring pass and has not had the source-verification sweep the others have. Even by its own guide, only cash on delivery completes: the card gateways still post to Litekart endpoints.
Cart
Not yet wired, by the coverage script’s measure.
Checkout
Wired: issues a real request to Medusa.
Sign-in (auth)
Not yet wired, by the coverage script’s measure.
Known gaps: auth, cart, product, category, search, address, user, payment-method — each is explained under Limitations below.
31 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 Medusa. You need Node.js and a Medusa to point it at; the storefront holds no data of its own.
Clone it, choose the connector, point it at Medusa
# 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/medusa-connector
# 3 — point it at your Medusa server
echo PUBLIC_MEDUSA_API_URL=http://localhost:9000 >> .env
echo PUBLIC_MEDUSA_PUBLISHABLE_API_KEY=pk_... >> .env
echo PUBLIC_MEDUSA_REGION_ID=reg_... >> .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_MEDUSA_API_URL | Yes | Base URL of the Medusa server’s Store API. |
PUBLIC_MEDUSA_PUBLISHABLE_API_KEY | Yes | A publishable API key created in the Medusa admin. Publishable keys are meant to be used from a browser. |
PUBLIC_MEDUSA_REGION_ID | Yes | The region ID (reg_…) used for pricing, currency and availability. |
PUBLIC_CONNECTOR | No | Only when more than one connector is installed: @misiki/medusa-connector names the one this build runs on. |
Boot checks only PUBLIC_MEDUSA_API_URL, but the guide marks all three as required. The Litekart trio is not used in Medusa mode.
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 Medusa
- Create a publishable API key in the Medusa admin and set it as
PUBLIC_MEDUSA_PUBLISHABLE_API_KEY. - Add the storefront’s origin to Medusa’s Store CORS configuration.
How the integration works
At boot, init in both hooks (through src/lib/core/connectors/init.ts) writes the three PUBLIC_MEDUSA_* values onto the connector’s BaseService — BASE_URL, PUBLISHABLE_KEY and REGION_ID. The server hook covers server rendering; the client hook covers the browser, which must reach the public Medusa URL in production.
By the guide’s account, cart, shipping rates and payment-method listing are Medusa-native; sign-in, sign-up, sign-out and password reset go through the Medusa SDK; categories map to Medusa product categories; and the profile page delegates to Medusa’s getMe and updateProfile. Medusa needs an email on the cart to complete an order, 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 — and CMS pages and the blog resolve empty. From connector 2.1.6 the REST paths it once inherited from Litekart are 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 cart, auth, product, category, search, address, user 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.
- Cart: not wired — the coverage script does not count it, though the guide describes the cart as Medusa-native.
- Products: not wired.
- Categories: not wired.
- Search: not wired.
- Saved addresses: not wired.
- User accounts: not wired.
- Payment-method listing: not wired.
- The card gateways in this connector — Razorpay, Stripe, PhonePe, PayPal, Cashfree, Affirm — still post to Litekart
/api/checkout/*endpoints and will not work without a Litekart API. Only cash on delivery completes through Medusa. - OTP sign-in is a mock:
getOtpreports success without sending anything. - Legal and CMS pages render their layout with empty content; the wishlist and the cart’s coupon drawer show empty states.
- 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 in Medusa mode without firing requests.
Troubleshooting
| When you see | What to do |
|---|---|
| Boot fails with “PUBLIC_MEDUSA_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/medusa-connector, or remove the variable if you meant to run another backend. With more than one connector installed, set PUBLIC_CONNECTOR='@misiki/medusa-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/medusa-connector'. |
[medusa] 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 Medusa 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 | Check the publishable API key, and that the deployed storefront’s origin is in Medusa’s Store CORS configuration. |
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 Medusa
Can I sell on Medusa with Svelte Commerce today?
Not yet. The coverage script counts the cart and sign-in as not wired, and CONNECTORS.md says the Medusa connector predates the current wiring pass. By its own guide, only cash on delivery completes; the card gateways still post to Litekart endpoints.
Why does the guide say the cart works when the coverage table says it does not?
They measure different things. 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, auth, products, categories or search. CONNECTORS.md lists Medusa as a next candidate for the source-verification sweep that would settle it.
What does Medusa need configured for Svelte Commerce?
A publishable API key created in the Medusa admin, a region ID for pricing and currency, and the storefront’s origin in Medusa’s Store CORS configuration.
Which payment methods work with Medusa?
Cash on delivery completes through the Medusa SDK. The card gateways in this connector — Razorpay, Stripe, PhonePe, PayPal, Cashfree, Affirm — still post to Litekart endpoints and do not work without a Litekart API.
Sources
This page summarises MEDUSA.md in the Svelte Commerce repository and the Medusa 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. Medusa 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. MEDUSA.md has the Medusa setup in full, beside the connector’s source.