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
21 of 43 services wired, read from CONNECTORS.md on ; npm may carry a newer patch. How coverage is measured.
What the connector calls on Sharetribe
The connector calls three Sharetribe surfaces: the Marketplace API under /v1/api for every resource route, the Authentication API under /v1/auth for /token and /revoke only, and the Asset Delivery API under /v1/assets/pub/<client id> on a separate host for Console-managed content.
Every Marketplace API call carries Authorization: bearer <access_token>, because Sharetribe has no unauthenticated mode; before the first call the connector posts a form-encoded client_credentials grant with scope=public-read to /v1/auth/token, a shopper signs in with the password grant and scope=user, and the tokens are kept in the connector’s in-memory credentials, not in a cookie.
| Service | What it requests |
|---|---|
product | GET /v1/api/listings/query with include=author,images,currentStock, fields.image, limit.images=4, page, perPage=24, keywords and sort; GET /v1/api/listings/show?id=<uuid> |
category | GET <asset host>/v1/assets/pub/<client id>/a/latest/listings/listing-categories.json for the tree; products by pub_categoryLevel1 on /listings/query |
search | GET /v1/api/listings/query with keywords, pub_ and meta_ attribute filters and price=MIN,MAX |
checkout | POST /v1/api/transactions/initiate and initiate_speculative with processAlias, transition and params; POST /v1/api/transactions/transition; GET /v1/api/process_transitions/query |
order | GET /v1/api/transactions/query and GET /v1/api/transactions/show?id=<uuid> with include=listing,provider,customer,booking,stockReservation |
auth | POST /v1/auth/token (password grant), then GET /v1/api/current_user/show; POST /v1/api/current_user/create to register; POST /v1/auth/revoke to sign out |
payment-method | GET /v1/api/current_user/show?include=stripeCustomer,stripeCustomer.defaultPaymentMethod; POST /v1/api/stripe_customer/add_payment_method and delete_payment_method |
review | GET /v1/api/reviews/query with page and perPage |
Sharetribe rules the connector follows
- The connector sets
Accept: application/jsonlast on every request, because without it Sharetribe answers in Transit, where ids and prices are typed objects that nothing in the connector decodes. - Sharetribe’s sort convention is the reverse of the storefront’s: a bare attribute sorts descending and a
-makes it ascending, so the storefront’s-createdAtis sent ascreatedAt, and with a keyword search the default sort is dropped so results stay in relevance order. - Prices are integers in the currency’s minor unit, so
1590in USD is shown as 15.90, a price-range filter is converted to minor units before it is sent, and zero-decimal and three-decimal currencies are handled separately. - Writes go through
?expand=true, because a Sharetribe command otherwise returns only a bare{ id, type }reference. - Token requests are single-flight so a burst of parallel calls fetches one token, and a 429 is retried up to three times, honouring
Retry-After, because development marketplaces allow 1 GET per second and 1 POST per 2 seconds per IP.
Read from the source of misiki-in/sharetribe-connector at commit 4e3d075 of . Where the code has changed since, the code is right.
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 devSwitching 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_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.
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.
Limitations on Sharetribe
- 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.
- If you set
PUBLIC_SHARETRIBE_API_SECRET, the client secret reaches every visitor: SvelteKit sendsPUBLIC_variables to the browser.
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.
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.
Sources
SHARETRIBE.md, read on ; CONNECTORS.md, read on ; the connector’s source at 4e3d075. Where they disagree with this page, they are right. Sharetribe is a trademark of its owner, named only to describe compatibility; see trademarks.