Svelte Commerce × Sharetribe
Svelte Commerce on Sharetribe
Sharetribe is a marketplace, not a webshop, so the connector maps a listing to a product and a transaction to an order. There is deliberately no cart, no coupon and no category tree, and the storefront’s buying path is inert.
- 21/43 services wired
- @misiki/sharetribe-connector 0.4.0
- Cart not yet wired
- Checkout wired
- Sign-in (auth) wired
What works on Sharetribe today
Listings, sign-in and orders are wired, but the storefront cannot buy through it yet. Sharetribe has no cart and no checkout: buying is a transaction on one listing, moved through the marketplace’s own process, with money moving only through Stripe Connect. The connector ships Sharetribe-native transaction commands; the storefront’s cart and payment step do not use them, and its gateway methods throw NotSupportedError.
Cart
Not yet wired, by the coverage script’s measure.
Checkout
Wired: issues a real request to Sharetribe.
Sign-in (auth)
Wired: issues a real request to Sharetribe.
Known gaps: cart, coupon, address, country, state, wishlist — each is explained under Limitations below.
21 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 Sharetribe. You need Node.js and a Sharetribe to point it at; the storefront holds no data of its own.
Clone it, choose the connector, point it at Sharetribe
# 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/sharetribe-connector
# 3 — point it at your Sharetribe marketplace
echo PUBLIC_SHARETRIBE_API_URL=https://your-store.example.com >> .env
echo PUBLIC_SHARETRIBE_CLIENT_ID=... >> .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_SHARETRIBE_API_URL | Yes | Base URL of the Marketplace API. Boot fails, naming this variable, if it is missing. |
PUBLIC_SHARETRIBE_CLIENT_ID | No | The Marketplace API application’s client ID — the OAuth2 client_id, and the path segment the Asset Delivery API authenticates with. PUBLIC_SHARETRIBE_API_KEY is read in its place if it is unset. |
PUBLIC_SHARETRIBE_API_KEY | No | Accepted as the client ID when PUBLIC_SHARETRIBE_CLIENT_ID is unset. |
PUBLIC_SHARETRIBE_API_SECRET | No | The client secret. See the limitations before setting it. |
PUBLIC_SHARETRIBE_ACCESS_TOKEN | No | A user access token, sent as a bearer token. Every transaction call needs one. |
PUBLIC_SHARETRIBE_ASSET_URL | No | The Asset Delivery API host, if it must be overridden. Defaults to https://cdn.st-api.com, a different host from the Marketplace API. |
PUBLIC_CONNECTOR | No | Only when more than one connector is installed: @misiki/sharetribe-connector names the one this build runs on. |
init.ts hands the connector every PUBLIC_SHARETRIBE_* variable that is set, camel-cased. The guide also lists PUBLIC_SHARETRIBE_ACCESS_KEY, PUBLIC_SHARETRIBE_STORE_ID and PUBLIC_SHARETRIBE_CHANNEL_ID; the connector’s source does not read them.
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 Sharetribe
- Create a Marketplace API application in Sharetribe; its client ID goes in
PUBLIC_SHARETRIBE_CLIENT_ID. - Let the storefront’s origin make cross-origin requests to Sharetribe (CORS): in production the browser calls
PUBLIC_SHARETRIBE_API_URLdirectly, not only the server.
How the integration works
The connector maps Sharetribe’s model onto the storefront’s: a listing becomes a product, a transaction becomes an order. It also reads Sharetribe’s Asset Delivery API, which lives on a different host from the Marketplace API.
Buying on Sharetribe is initiating a transaction on one listing and moving it through the marketplace’s own transaction process, whose aliases and transitions are specific to each marketplace. The connector ships commands for that; it does not guess the process names, because a wrong guess fails. The storefront’s cart and per-gateway checkout have no Sharetribe equivalent, so they throw rather than return a fake receipt.
Installing the package is the whole switch. vite.config.ts resolves whichever @misiki/*-connector is installed, and src/lib/core/connectors/init.ts hands it every PUBLIC_SHARETRIBE_* 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.
There is no Litekart API behind the storefront here, so store identity — name, logo, currency, menus, plugin toggles, theme colours — comes 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”. Any Litekart REST path the connector still inherits is answered from that local data, or resolved empty, rather than requested.
Limitations
- The storefront cannot complete a purchase. Its payment step calls one method per gateway, keyed by a cart; Sharetribe has neither, and money moves only through Stripe Connect inside a transaction. Each gateway method throws
NotSupportedError, and the connector’s Sharetribe-native transaction commands are not called by the storefront yet. - Cart: not wired — deliberately: Sharetribe has no cart, so the storefront’s cart is inert.
- Coupons: not wired — deliberately: Sharetribe has no coupons.
- Saved addresses: not wired.
- Countries: not wired.
- States and regions: not wired.
- Wishlist: not wired.
- Pages that depend on a service that is not wired render their empty state rather than failing.
- If you set
PUBLIC_SHARETRIBE_API_SECRET, the client secret reaches every visitor: SvelteKit sendsPUBLIC_variables to the browser. - 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.
Troubleshooting
| When you see | What to do |
|---|---|
| Boot fails with “the sharetribe connector is active but PUBLIC_SHARETRIBE_API_URL is not set” | Add PUBLIC_SHARETRIBE_API_URL 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 — a fresh clone also lists @misiki/vendure-connector — or set PUBLIC_CONNECTOR='@misiki/sharetribe-connector'. |
| 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 | Store identity is static on this backend. Set name, logo, currencyCode and the rest in the default export of kitcommerce.config.ts; src/lib/core/connectors/default-store.json lists every field. |
[sharetribe] 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 Sharetribe 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. |
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.
An open question for Sharetribe’s maintainers: Is listing to Product the mapping you would recommend, or should a storefront model transactions as the primary entity?
FAQ
Questions about Svelte Commerce on Sharetribe
Can I run a Sharetribe marketplace on Svelte Commerce today?
Not to take bookings or sales. Listings, sign-in and orders are wired, but Sharetribe has no cart and no checkout, and the storefront’s buying path expects both. The connector has Sharetribe-native transaction commands; the storefront does not call them yet.
How do I switch Svelte Commerce to Sharetribe?
Remove the connectors the storefront ships with, install @misiki/sharetribe-connector, set PUBLIC_SHARETRIBE_API_URL in .env and start the dev server. vite.config.ts resolves whichever connector is installed, so no file in the storefront changes.
Why is there no cart on Sharetribe?
Because Sharetribe does not have one. Buying is a transaction on a single listing, moved through the marketplace’s own process. The connector maps listings to products and transactions to orders, and leaves the cart and coupons deliberately empty. Its authors have asked Sharetribe’s maintainers whether that mapping is the one they would recommend.
Has the Sharetribe connector been run against a real Sharetribe store?
Not against a live production instance — no Svelte Commerce connector has been. It was written by reading Sharetribe’s authoritative API source, and the Svelte Commerce maintainers ask Sharetribe’s own maintainers for a sandbox to run it against.
Sources
This page summarises SHARETRIBE.md in the Svelte Commerce repository and the Sharetribe 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. Sharetribe 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. SHARETRIBE.md has the Sharetribe setup in full, beside the connector’s source.