Svelte Commerce × Vendure
Svelte Commerce on Vendure
Vendure’s GraphQL Shop API covers almost the whole storefront surface, which puts this connector level with Litekart as the most complete of the 26. Products, cart, checkout, sign-in, orders and addresses come live from Vendure; store identity and CMS-style content come from the storefront’s own config.
- 39/43 services wired
- @misiki/vendure-connector 2.0.35
- Cart wired
- Checkout wired
- Sign-in (auth) wired
What works on Vendure today
As complete as any connector here: 39 of 43 services, with cart, checkout and sign-in wired. What the connector does not implement for Vendure yet — wishlist, reviews, coupons, CMS pages, several currencies, multi-vendor — renders an empty state rather than an error.
Cart
Wired: issues a real request to Vendure.
Checkout
Wired: issues a real request to Vendure.
Sign-in (auth)
Wired: issues a real request to Vendure.
Known gaps: none recorded.
39 of 43 services wired, read from CONNECTORS.md on ; npm may carry a newer patch. How coverage is measured.
What the connector calls on Vendure
The connector sends every request as a GraphQL POST to Vendure’s Shop API at <PUBLIC_VENDURE_API_URL>/shop-api, with credentials: 'include'.
A shopper signs in with the Login mutation; the connector takes the session token from the vendure-auth-token response header, keeps it in localStorage as vendure_auth_token and sends it back as Authorization: Bearer on each request.
| Service | What it requests |
|---|---|
product | GetProducts (products) with options.skip, options.take, options.filter.name.contains and options.sort.createdAt; GetProduct by slug for a product page |
category | GetCategories (Vendure collections) with list options, and GetCategory by slug |
search | SearchProducts (search) with term, skip, take, groupByProduct: true and an optional collectionSlug |
cart | ActiveOrder, AddItemToOrder, AdjustOrderLine, RemoveOrderLine, ApplyCouponCode and RemoveCouponCode, all against the session’s active order |
checkout | SetCustomerForOrder, SetOrderShippingAddress and SetOrderBillingAddress, then TransitionOrderToState to ArrangingPayment, then AddPaymentToOrder; the payment-method list is GetEligiblePaymentMethods, keeping only methods with isEligible |
order | CustomerOrders (activeCustomer.orders, newest first, 10 a page) and OrderByCode |
auth | Login, RegisterCustomerAccount, VerifyCustomerAccount, RequestPasswordReset, ResetPassword, Logout and GetActiveCustomer |
address | ActiveCustomerAddresses, CreateCustomerAddress, UpdateCustomerAddress and DeleteCustomerAddress |
Vendure rules the connector follows
- A failed GraphQL operation can still answer HTTP 200, so the connector reads the
errorsarray on every response and theerrorCodeof Vendure’sErrorResulton each mutation. - The connector replaces its stored token whenever a response carries a new
vendure-auth-tokenheader, and it drops the token onerror.no-customer-found-for-current-user. - Before payment the connector reads the active order and stops with a message if it has no customer, then records the order
code, becauseAddPaymentToOrderreturns no order number. - A second
TransitionOrderToStatetoArrangingPaymentcomes back asORDER_STATE_TRANSITION_ERROR, and the connector treats that case as success and rereads the active order. - Cash on delivery adds a payment with the method code
standard-payment, point of sale withpos, and Razorpay withrazorpay, so the Vendure server needs payment methods under those codes.
Read from the source of misiki-in/vendure-connector at commit cb53eb6 of . Where the code has changed since, the code is right.
Quick start
From nothing to a Svelte Commerce storefront reading Vendure. You need Node.js and a Vendure to point it at; the storefront holds no data of its own.
Clone it, choose the connector, point it at Vendure
# 1 — get the storefront
git clone https://github.com/itswadesh/svelte-commerce
cd svelte-commerce
# 2 — swap the stock connector for Vendure’s
npm uninstall @misiki/litekart-connector
npm i @misiki/vendure-connector
# 3 — point it at your Vendure server
echo PUBLIC_VENDURE_API_URL=http://localhost:3000 >> .env
# 4 — run it
npm run devThe GraphQL endpoint is resolved as <PUBLIC_VENDURE_API_URL>/shop-api, so give the server’s base URL, not the endpoint.
Switching works the same way on every backend: what all 26 share, from one connector at a time to store identity.
Environment variables
| Variable | Required | What it does |
|---|---|---|
PUBLIC_VENDURE_API_URL | Yes | Base URL of the Vendure server. GraphQL calls go to <this URL>/shop-api. |
PUBLIC_CONNECTOR | No | Only when more than one connector is installed: @misiki/vendure-connector names the one this build runs on. |
The Litekart trio — PUBLIC_LITEKART_API_URL, PUBLIC_LITEKART_STORE_ID, PUBLIC_LITEKART_DOMAIN — is not needed in Vendure mode; /health reports ready as soon as PUBLIC_VENDURE_API_URL is set.
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 Vendure
- Set
authOptions.requireVerificationtofalse. - Allow the storefront’s origin in Vendure’s CORS settings, with credentials. The browser calls
PUBLIC_VENDURE_API_URLdirectly and the connector sendscredentials: 'include', soAccess-Control-Allow-Originmust echo the exact origin — not*— andAccess-Control-Allow-Credentialsmust betrue.
How the integration works
At boot, init in both src/hooks.server.ts and src/hooks.client.ts reads PUBLIC_VENDURE_API_URL and hands it to the connector’s setBaseUrl(). Both hooks matter: the server hook covers server rendering, the client hook covers the browser, which must reach the public Vendure URL in production.
Products, categories (Vendure collections), search, cart, checkout, payment methods, orders, sign-in, profile and addresses all go to Vendure’s Shop API. Checkout attaches the customer before payment — an order cannot reach ArrangingPayment without one — and carries Vendure’s order code out as the order number.
Store identity, menus and plugin toggles come from src/lib/core/connectors/default-store.json merged under the default export of kitcommerce.config.ts; until you override it, the store is called “Test”. CMS pages and the blog resolve empty. From connector 2.0.39 the REST paths it once inherited from Litekart are answered by the connector itself.
Two defaults in that static config shape what shoppers see. The search icon in the navigation is hidden (plugins.search.active is false, because autocomplete is Litekart’s Meilisearch), though Vendure’s own search still powers the /products page. And sign-in offers email and password only (loginType is EMAIL): Vendure has no OTP, while email sign-in, sign-up, sign-out and password reset are native GraphQL.
Limitations on Vendure
- CONNECTORS.md records no known gaps for Vendure; the Vendure guide itself lists what is not implemented yet: wishlist, reviews, coupons, several currencies and regions, Meilisearch faceted search, CMS content and multi-vendor.
- Legal and CMS pages render their layout with empty content.
- Wishlist shows an empty state, and toggling it says “Wishlist is not available on this store”; the cart’s coupon drawer lists none.
- No OTP sign-in:
getOtpthrows. - If the Vendure 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 detects the connector and stays hidden without firing requests.
Troubleshooting Vendure
| When you see | What to do |
|---|---|
| Boot fails with “PUBLIC_VENDURE_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 — the stock Litekart one, say. Install @misiki/vendure-connector, or remove the variable if you meant to run Litekart. With more than one connector installed, set PUBLIC_CONNECTOR='@misiki/vendure-connector'. |
| Sign-in or cart works in dev but not when deployed | Almost always Vendure’s CORS: allow the deployed storefront’s origin with credentials, as described under the Vendure settings above. |
Before you rely on it
No connector has been exercised against a live production instance of its platform; each was written from the platform’s published source. The limits every backend shares and the errors every switch can meet are on the backends page.
Offer a sandbox or a correctionFAQ
Questions about Svelte Commerce on Vendure
Can I run a Vendure store on Svelte Commerce today?
It is the most complete option besides Litekart: 39 of 43 services, with cart, checkout and sign-in wired against Vendure’s GraphQL Shop API. What the connector does not implement for Vendure yet — wishlist, reviews, coupons, CMS pages, multi-vendor — shows an empty state. Like every connector, it has not been run against a live production Vendure store.
Which Vendure settings does Svelte Commerce need?
Two. Set authOptions.requireVerification to false, and allow the storefront’s origin in CORS with credentials — the exact origin, not *, with Access-Control-Allow-Credentials set to true.
Why does sign-in work locally but not once deployed?
Because the browser calls Vendure directly with credentials, and Vendure’s CORS settings must name the deployed storefront’s origin. Add it, with credentials allowed.
Does Svelte Commerce use Vendure’s search?
Yes, on the /products catalogue page. The search icon in the navigation is hidden by default, because that autocomplete is Litekart’s Meilisearch, which Vendure does not have.
Sources
VENDURE.md, read on ; CONNECTORS.md, read on ; the connector’s source at cb53eb6. Where they disagree with this page, they are right. Vendure is a trademark of its owner, named only to describe compatibility; see trademarks.