Sharetribe’s architecture is an open client bolted onto a closed, hosted backend
The only piece of Sharetribe you can put in your own repository is sharetribe-web-template (opens in a new tab), an Apache-2.0 licensed React and Redux client you clone, customise and host yourself. Everything that client talks to — the Marketplace API, the Integration API, Console (Sharetribe’s own admin dashboard) and the transaction engine that runs your checkout state machine — is closed source and hosted exclusively by Sharetribe (opens in a new tab). There is no self-hosted or on-premise path for that backend at any plan tier.
flowchart LR
subgraph YourRepo["Your repository (Apache-2.0)"]
Client["sharetribe-web-template<br/>React + Redux + Express"]
end
subgraph Sharetribe["Sharetribe-hosted, closed source"]
MarketplaceAPI["Marketplace API"]
IntegrationAPI["Integration API"]
AuthAPI["Authentication API (OAuth2)"]
AssetAPI["Asset Delivery API"]
Console["Console"]
TxEngine["Transaction engine"]
end
Client --> MarketplaceAPI
Client --> AuthAPI
Client --> AssetAPI
Console --> TxEngine
IntegrationAPI --> TxEngine
MarketplaceAPI --> TxEngine
Sharetribe exposes four REST APIs (opens in a new tab): Marketplace, Integration, Authentication (OAuth2) and Asset Delivery. There is no GraphQL option, so every integration you write speaks the same REST-plus-OAuth2 shape. Dev and Test environments throttle requests (opens in a new tab) to roughly 60 queries and 30 commands a minute; Live environments are currently unmetered except for one Integration API endpoint, which Sharetribe itself frames as provisional rather than guaranteed.
Checkout and booking behaviour lives in a transaction process (opens in a new tab): a finite-state machine defining who can do what, in what order, and which side effects fire on each transition. Console gives you toggles for the built-in processes; anything beyond that means pulling the process’s process.edn file, editing transitions and actions in EDN — Clojure’s plain-text data format — and pushing the result back with the Sharetribe CLI (opens in a new tab).
sharetribe-cli login
sharetribe-cli process pull \
--process=default-booking \
--path=./transaction-processes/default-booking \
--marketplace=<YOUR_MARKETPLACE_ID>Confirm the exact flags against Sharetribe’s own CLI reference before running this against a real marketplace — flag names have shifted across CLI versions and this example shows the shape of the command, not a guaranteed-current invocation.
That open client layer currently pins react 18.3.1, react-dom 18.3.1, react-router-dom 5.3.4, @reduxjs/toolkit 2.12.0, react-redux 9.2.0 and express 5.2.1 (opens in a new tab), on Node ^22.22.0 or >=24.0.0 — the only layer of the stack you can inspect in git blame.
You should now see: which half of Sharetribe you can inspect and version-control — the template — and which half you rent for as long as you run the marketplace: the API, Console and transaction engine.
What Sharetribe costs in 2026, and where the real TCO hides
Sharetribe runs four live plans, priced on transaction volume rather than seats. Build (opens in a new tab) costs $39/month but is a dev/test sandbox only — zero live transactions run on it. Lite starts live traffic at $99/month billed annually (or $139 month-to-month) with 50 free transactions included; Pro is $199/$259 with 250 free; Extend is $299/$389 with 500 free.
Every plan charges up to $0.19 per initiated transaction once you clear the free allowance, with volume discounts (opens in a new tab) applying at higher volumes without published thresholds. That per-transaction fee is separate from Stripe Connect Custom’s own processing fee, which stacks on top of both the subscription and the overage charge and varies by country and card type. Total cost of ownership (TCO) — what the marketplace actually costs to run, not the sticker subscription — only appears once you add these together against your real transaction count.
None of that pricing covers clearing Sharetribe’s built-in limits. Removing the 100-unit stock cap, adding a second currency, or supporting partial refunds all require custom code against the Integration API or a modified transaction process — developer time the pricing page doesn’t quote, because it isn’t Sharetribe’s cost to estimate.
Subscription (Pro, billed annually): $199.00
Free transaction allowance: 250
Transactions this month: 800
Overage transactions: 800 - 250 = 550
Overage fee (up to $0.19 each): 550 x $0.19 = $104.50
Subscription + overage: $199.00 + $104.50 = $303.50
Plus: Stripe Connect Custom processing fees, billed separately by Stripe
and varying by country and card typeflowchart TB
subgraph Included["Included in the Sharetribe subscription"]
Sub["Monthly plan fee"]
Free["Free transaction allowance"]
end
subgraph Extra["Costs extra, billed separately"]
Overage["Overage: up to $0.19 per transaction past the free allowance"]
StripeFee["Stripe Connect Custom processing fees"]
Dev["Developer time: stock cap, multi-currency, partial refunds"]
end
Free -. grows past the allowance .-> Overage
You should now see: a monthly cost estimate built from your own GMV and transaction count, not just the advertised sticker price.
Where Sharetribe validates a marketplace fastest: rental, booking and service models
Sharetribe’s default transaction process is built around bookable time slots and a request-accept-deliver-review flow, which is exactly the shape of equipment rental, space booking, freelance services and peer-to-peer marketplaces. You configure listing types, availability and pricing in Console rather than writing a state machine from scratch, because Sharetribe already shipped the one these categories need — see Build any type of marketplace with Sharetribe (opens in a new tab) for the listing types covered out of the box.
Stripe Connect Custom splits a booking payment between your marketplace fee and an individual provider’s payout without you writing payment-routing code. That is the payout shape a two-sided rental or service marketplace actually needs — money in from the customer, a share out to the host or freelancer — and it is live from the Lite plan up (opens in a new tab).
Sharetribe’s MCP server (opens in a new tab) — Model Context Protocol, the standard AI coding tools use to reach external documentation — went live on 24 June 2026, connecting Claude Code, Cursor and VS Code to Sharetribe’s docs through a single search_sharetribe_knowledge_sources tool. It speeds up configuring a proof of concept by answering setup questions inline, but it performs no write actions: no agent can create a listing, edit a transaction process, or issue a refund through it today. See Build with AI (opens in a new tab) for what it does cover.
All of this — listing types, availability rules, Stripe Connect payouts, MCP-assisted configuration — stays inside Console’s supported settings. A founder can reach a testable, two-sided marketplace without touching the CLI or an EDN file.
You should now see: whether your own idea — rental, booking, freelance service or peer-to-peer — matches the flows Sharetribe supports natively, before writing any code.
Where Sharetribe’s ceiling sits: retail catalogues and highly custom commerce
The no-code configuration hard-caps a single transaction at 100 units of stock, even when a listing’s stock type (opens in a new tab) is set to infinite. A shopper trying to buy 250 units of an “unlimited” listing is stopped at 100 — not a Console setting away from fixed, but a rebuild of the purchase logic away.
A marketplace runs one currency by default, set once in Console under Build > General > Localization, documented in currency configuration (opens in a new tab). Multi-currency needs custom code, because a listing carries exactly one price attribute — filter for “price under 500” across a USD listing and a JPY listing and the result is nonsense, not two prices of the same product.
Refunds run only through Sharetribe’s own stripe-refund-payment transaction action (opens in a new tab), and that action issues a full refund. There is no partial-refund action in the default process, so a support agent who wants to refund half a booking has no built-in path to do it.
PayPal and other wallets are excluded from the built-in payment integration for a structural reason, not an oversight: Sharetribe’s Stripe Connect destination charges depend on Stripe’s on_behalf_of parameter, which names the connected account as the seller of record, and PayPal can’t support it (opens in a new tab). A market where PayPal is the default checkout method has no first-party fallback.
These four limits compound for a retail catalogue business specifically, because bulk orders, regional pricing, partial refunds and local payment methods aren’t four separate edge cases for that model — they’re the same launch requirement hit four times.
You should now see: whether your own product catalogue and checkout requirements clear these four documented limits or hit the ceiling immediately.
Sharetribe’s modernity and AI-readiness scores, and how they were calculated
Sharetribe Web Template’s package.json (opens in a new tab) mixes current and legacy choices in the same dependency tree. React 18.3.1 and Redux Toolkit 2.12.0 are current majors; react-router-dom is pinned to 5.3.4, the legacy major that predates the v6 rewrite, not v6 or v7. The server side of the template is a vendored copy of Create React App, a build tool its own maintainers stopped developing.
That server dependency has a hosting consequence that counts directly against modernity: Sharetribe’s own template introduction (opens in a new tab) states serverless platforms can’t run it, because it needs a persistent Node/Express process rather than a request-scoped function. A team assuming a serverless deploy target finds this out at deploy time, not gradually.
AI-readiness runs on a narrower question: can an agent act on a live marketplace, or only look things up? The MCP server, live since 24 June 2026, gives coding assistants documentation search through search_sharetribe_knowledge_sources and nothing else. No agent can create a listing, edit a transaction process, or issue a refund through it today — every write still goes through Console, the CLI, or hand-written Integration API calls.
The four REST APIs (opens in a new tab) with OAuth2 auth are a determinate integration surface — documented, versioned, callable directly by any HTTP client an agent can drive — but they’re a conventional API, not a natural-language action layer built for agents specifically. There’s no GraphQL and no agent-native write path.
Put plainly: modernity here means a current UI layer wrapped around a legacy router and a discontinued build tool, not an outdated stack overall. AI-readiness means documentation-only today — genuinely useful for speeding up a human building a proof of concept, not yet capable of acting on your behalf.
You should now see: exactly which facts produced each band, so you can re-weight them for your own priorities instead of trusting a single number.
The production risk: Stripe refunds can desync from Sharetribe’s transaction state
Sharetribe’s transaction state machine only advances through its own stripe-refund-payment action, and that action issues a full refund. There is no partial-refund transition in the default process — worth repeating from the ceiling section above, because here it isn’t a missing feature, it’s the setup for an operational failure.
A support agent handling a complaint has an obvious move: open Stripe’s dashboard and refund 30% of the booking directly. Stripe processes that correctly. Sharetribe’s transaction record doesn’t hear about it — it still shows the booking as fully paid or still active, because nothing told the state machine a refund happened outside its one built-in action.
sequenceDiagram
participant Agent as Support agent
participant Stripe
participant Sharetribe as Sharetribe transaction
Agent->>Stripe: Issue 30% refund (dashboard)
Stripe-->>Agent: Refund confirmed
Note over Sharetribe: stripe-refund-payment action never fired
Agent->>Sharetribe: Check booking status
Sharetribe-->>Agent: Still shows fully paid / active
There are exactly two fixes, and neither is a Console setting. Train every support agent to never refund directly in Stripe — full refunds only, through Sharetribe’s own action — or write a custom transition into the transaction process, in EDN via the CLI, that reconciles a partial-refund amount back into Sharetribe’s state when Stripe reports one.
The same pattern — a hosted system whose state you don’t fully control — shows up in the serverless-hosting restriction from the section above. Both fail the same way: not by degrading gracefully, but by breaking outright the moment a team’s assumption diverges from what Sharetribe’s architecture actually supports.
You should now see: the specific support-desk mistake that causes Stripe and Sharetribe to disagree, and the two ways to prevent it before go-live.
Who should shortlist Sharetribe, and who should keep looking
Shortlist Sharetribe if the idea is rental, booking, freelance service or peer-to-peer, needs Stripe Connect-style payouts to individual providers, runs in one currency, and the goal is validating demand before committing engineering budget to custom transaction logic. That’s the fit described in the sections above, and it’s a fast one.
Don’t shortlist Sharetribe as-is for a retail catalogue that needs bulk orders over 100 units per transaction, multi-currency pricing, partial refunds, or PayPal and local wallet support. Each of those needs custom development or a different platform — not a Console setting you haven’t found yet.
There’s a middle case: a team with developer capacity to edit process.edn through the CLI and build against the Integration API can push past some of these limits. That’s a legitimate path, but it’s a development project with its own timeline and maintenance cost, not the no-code configuration this review is scoped to.
flowchart TD
Start["What kind of marketplace?"] --> Q1{"Rental, booking,\nservice or P2P?"}
Q1 -->|Yes| Q2{"One currency, full refunds only,\nStripe accepted everywhere?"}
Q1 -->|No, retail catalogue| Ceiling["Hits the ceiling:\ncustom dev or different platform"]
Q2 -->|Yes| Fit["Clean fit: shortlist Sharetribe"]
Q2 -->|No| Q3{"Developer capacity to edit\nprocess.edn via CLI?"}
Q3 -->|Yes| Custom["Custom-dev-required:\nextend past the limit"]
Q3 -->|No| Ceiling
The real decision is whether you need validation speed or long-term architectural control. Sharetribe is very good at the first. Its closed backend — no self-hosted Marketplace API, Console, or transaction engine at any plan tier — doesn’t offer the second, at $99/month or at $389.
You should now see: which of three buckets your own marketplace idea falls into — clean fit, hard blocker, or custom-dev-required — and whether to proceed to a proof of concept.
Five questions to answer before committing to a Sharetribe proof of concept
Answer these against a Test-environment account before signing an annual contract, not after.
- Stock volume. Does any single transaction need more than 100 units of one listing? Test it in a Test-environment checkout with the listing’s stock type set to infinite.
- Currency. Does the catalogue need more than one currency or region-scoped pricing? Check Console > Build > General > Localization and try listing the same product priced in two currencies.
- Refunds. Does the support workflow require partial refunds? Issue one through Stripe’s dashboard against a test transaction and check whether the Sharetribe transaction record updates.
- Payment methods. Does the target market expect PayPal or a non-Stripe wallet at checkout? Confirm Stripe Connect Custom is acceptable in every launch country.
- Hosting. Does the team’s hosting standard require serverless deployment? Confirm budget and ownership for an always-on Node/Express process instead.
You should now see: a five-question checklist that surfaces every documented ceiling in this review before you sign a Lite, Pro or Extend contract.
Limitations
This review covers the free/no-code Console configuration and the four REST APIs; it doesn’t cover Sharetribe’s search relevance tuning, its notification and email templating system, or its enterprise contract terms, none of which change the four ceiling limits above but each of which has its own learning curve. The CLI command shown illustrates the shape of a process pull; confirm exact flags against Sharetribe’s own CLI reference before running it against a real marketplace, since flag names have changed across CLI versions.
The MCP server has been live only since 24 June 2026 at the time of writing, so its write capability could change faster than this review does — check Sharetribe’s changelog before assuming the documentation-only limitation still holds. Nothing here was run against a live Sharetribe account for this article; every Console path, pricing figure and API behaviour is drawn from Sharetribe’s own published documentation, not from a reproduced test transaction, so treat the worked cost example as a calculation from stated prices, not a billed invoice. Sharetribe’s volume-discount thresholds beyond the published per-transaction fee aren’t public, so any total above the free allowance should be treated as an estimate until confirmed with Sharetribe directly.