This review is written against Saleor Core 3.23.22, the latest stable tag on the 3.23 line, targeting a reference environment of Ubuntu 24.04 LTS, Docker 28.1.1 and PostgreSQL 17.5 as the host database. The GraphQL-first architecture and per-channel multi-channel model hold up under inspection. Where the evidence gets thinner is the “AI-ready” framing: the shipped MCP server only reads, and Saleor’s own agentic-commerce roadmap calls its standards layer “coming as open source” rather than something you can install today. The GraphQL and MCP responses quoted below have not been run against a live instance in this pass — each is marked for capture rather than reconstructed, so treat them as the shape to expect rather than a transcript.
Who should shortlist Saleor, and who should walk away
Shortlist Saleor if your team already ships GraphQL and React in production and needs channel-scoped catalogues — separate pricing, tax and stock per brand, region or business line — without forking the codebase. Saleor Core (opens in a new tab) is BSD-3-Clause with no field-of-use restriction, so the composable claim is not marketing copy: you can self-host, fork and modify the engine outright.
Shortlist too if the AI-agent use case you have in mind is read-heavy: product lookup, order status, inventory checks. That is the actual boundary of the shipped MCP server (opens in a new tab), and the section below walks through it in detail.
Walk away if you expect a storefront in the box. Saleor Core ships no frontend — the closest thing is a separate, optional reference Next.js storefront (opens in a new tab) that your team then owns and maintains as its own codebase. Walk away too if any part of the roadmap depends on an agent placing orders or writing records today; the shipped integration does not do that. And walk away if your GMV is spiky — a flash sale or a seasonal peak turns Cloud’s usage-based overage into a bill you did not model.
This is one review in a series that scores every platform against the same fixed criteria, so read it as one data point, not a ranking against platforms this piece does not name.
flowchart TD
A[Evaluating Saleor?] --> B{Team already runs<br/>GraphQL + React?}
B -- No --> W1[Walk away, or budget<br/>for a stack change]
B -- Yes --> C{Need a storefront<br/>out of the box?}
C -- Yes --> W2[Walk away: Saleor ships<br/>no storefront]
C -- No --> D{AI agent needs to<br/>write orders or records today?}
D -- Yes --> W3[Walk away: MCP server<br/>is read-only]
D -- No --> E{GMV volatile<br/>or spiky?}
E -- Yes --> W4[Model Cloud overage<br/>risk before committing]
E -- No --> S[Shortlist Saleor]
What Saleor Cloud actually costs once GMV overage kicks in
Saleor Cloud prices on a flat monthly fee plus usage-based overage tied to gross merchandise value (GMV), and the sticker price is not the number that lands on your invoice once you cross the plan’s GMV ceiling. The published pricing (opens in a new tab) has four tiers.
Sandbox is free, meant for prototyping, and is the only tier where Saleor documents a request-rate limit: 120 requests per minute, with HTTP 429 on breach. Select costs $1,599/month and covers up to $200,000 GMV/month; orders beyond that ceiling are billed at 0.8% overage. Volume costs $3,999/month, covers up to $1,000,000 GMV/month, and drops the overage rate to 0.4%. Enterprise is custom-quoted, with overage described as “as low as 0.2%” — the real number depends on the deal you negotiate.
Work through a realistic case: a store on Select running $350,000 GMV in a given month is $150,000 over the plan’s $200,000 ceiling. At 0.8% overage, that is an extra $1,200, for a total bill of $2,799 that month — 75% more than the flat $1,599 sticker price. Run that arithmetic against your peak month, not your average month, since overage is what turns a predictable line item into one tied to sales performance.
Self-hosting Saleor Core removes the GMV-based fee entirely: you pay for infrastructure and the ops time to run it, not a percentage of revenue. What self-hosting does not give you is the one-click install flow in the Saleor App Store (opens in a new tab) — that marketplace experience is Cloud-exclusive. Most Apps are themselves open source (opens in a new tab), so a self-hosted team can still use them, just by deploying and registering each App’s manifest manually rather than clicking install.
The real decision here is not which tier is cheapest — it is build-vs-buy: pay Saleor a percentage of GMV for managed infrastructure and App Store convenience, or pay your own team to run the stack and wire up Apps by hand.
GraphQL-only by design: no REST API, no shipped storefront
Saleor exposes GraphQL only — there is no REST API, and there is no REST fallback bolted onto the current architecture. Every integration, from a storefront to an internal ops tool to an AI agent, talks to the same endpoint using the same query language.
Saleor Core also ships no storefront. What the project calls a “storefront” is a separate, optional reference Next.js application (opens in a new tab) built with TypeScript, GraphQL and Tailwind CSS — code your team clones, deploys and then owns, not a hosted product Saleor maintains for you.
GraphQL’s flexibility comes with a cost model attached: query cost is calculated from the objects a query requests (opens in a new tab), not the objects it returns, and every response carries that number in an extensions.cost object.
query ProductList {
products(first: 10, channel: "default-channel") {
edges {
node {
id
name
pricing {
priceRange {
start {
gross {
amount
currency
}
}
}
}
}
}
}
}Expected output:
Paginated fields are capped at 100 items per page, regardless of plan — asking for first: 150 does not unlock more items on a higher tier, it produces an error.
query TooManyProducts {
products(first: 150, channel: "default-channel") {
edges {
node {
id
}
}
}
}Expected output:
The practical implication is that query-cost budgeting is not a one-time integration task. Every field a frontend team adds to a query changes its cost, so cost-ceiling checks belong in ongoing code review, not just in initial API design.
Multi-channel is real; multi-currency per channel is not
A Saleor channel (opens in a new tab) represents exactly one sales context — a region, a brand, a business line, or an external marketplace — and each channel carries exactly one currency, plus its own price, tax, stock and staff permission scope. There is no per-channel list of supported currencies; there is one currencyCode field, fixed at channel creation.
query ChannelCurrencies {
channels {
id
name
slug
currencyCode
}
}Expected output:
Serving three currencies means creating at least three channels, not adding three currency fields to one channel. Teams that assume a single channel named something like “EU” can cover a multi-currency region (opens in a new tab) find out otherwise only after storefront pricing comes back in the wrong currency for part of that region.
Multi-region storefront routing — subdomain-based, IP-based redirection, or an explicit channel selector in the UI — is left entirely to the storefront. Saleor does not ship logic that maps a visitor to a channel.
Channel count therefore scales as currency count multiplied by business-line count. A brand selling in three currencies across two business lines is not three channels — it is six, and each one needs its own pricing and stock sync.
flowchart LR
subgraph Assumption["Common wrong assumption"]
EU1[EU region] --> C1["One channel: 'eu'"]
C1 --> X1[EUR?]
C1 --> X2[GBP?]
C1 --> X3[SEK?]
end
subgraph Reality["How channels actually work"]
EU2[EU region] --> CA[Channel: eu-eur] --> A1[EUR only]
EU2 --> CB[Channel: eu-gbp] --> A2[GBP only]
EU2 --> CC[Channel: eu-sek] --> A3[SEK only]
end
Saleor’s MCP server can answer questions; it cannot place an order
Saleor’s official MCP server (github.com/saleor/saleor-mcp (opens in a new tab)) is explicit about its own limits: the documentation states it “doesn’t trigger any mutations in the Saleor API.” Model Context Protocol (MCP) is the open standard that lets an LLM-based agent call external tools through a defined schema instead of screen-scraping — Saleor’s server exposes Saleor’s GraphQL API to an MCP client as a set of read tools only.
The server still requires an auth token scoped with MANAGE_PRODUCTS and MANAGE_ORDERS permissions (opens in a new tab), even though the shipped tool set never exercises the write half of either grant — worth noting if your policy is to scope tokens as tightly as the actual usage.
The production instance at mcp.saleor.app is stated to be compatible with Saleor 3.21+ and scoped to Cloud-hosted instances only; a self-hosted deployment needs to run its own MCP server rather than pointing at Saleor’s hosted one.
{
"method": "tools/call",
"params": {
"name": "get_order",
"arguments": {
"id": "<ORDER_ID>"
}
}
}Expected output:
{
"method": "tools/call",
"params": {
"name": "create_order",
"arguments": {
"channel": "default-channel"
}
}
}Expected output:
sequenceDiagram
participant Agent as AI agent
participant MCP as Saleor MCP server
participant API as Saleor GraphQL API
Agent->>MCP: tools/call get_order
MCP->>API: query { order(id: ...) { ... } }
API-->>MCP: order data
MCP-->>Agent: result: order JSON
Agent->>MCP: tools/call create_order (hypothetical)
MCP--xAgent: error: no write tool exposed
Contrast that shipped boundary with Saleor’s own agentic-commerce marketing page (opens in a new tab), which positions Saleor as “the operating system for agentic commerce” and describes an embeddable agentic chat plus open agentic-commerce standards. The page states the standards work is “Coming as open source” and never names MCP — it describes a future layer, not the one reviewed above.
The trust primitive that is actually shipped is signed webhooks (opens in a new tab). Since Saleor 3.5, a webhook without a configured secretKey is signed with a detached JWS using RS256, verifiable against the public key at /.well-known/jwks.json; a webhook with a secretKey instead carries an HMAC-SHA256 signature in the Saleor-Signature header.
POST /webhooks/order-created HTTP/1.1
Host: your-integration.example.com
Content-Type: application/json
Saleor-Signature: <jws-or-hmac-signature>
Saleor-Event: order_created
Saleor-Api-Url: https://<your-instance>.saleor.cloud/graphql/
{"order": {"id": "<ORDER_ID>", "status": "unfulfilled"}}Verify a secretKey-signed payload by recomputing an HMAC-SHA256 digest of the raw request body and comparing it to the Saleor-Signature header. Verify an unsigned-secret payload by fetching /.well-known/jwks.json and validating the detached JWS against the published RSA public key.
Scoring this against evidence, not marketing: 6/10 for AI/agent-readiness. Points for signed, verifiable webhooks and for permission groups (opens in a new tab) granular enough to scope a token narrowly. Points deducted because there is no shipped write path for an agent, and because the agentic-commerce page describes capability that is not yet open source.
Known pitfall: an agent wired to this MCP server correctly answers “what’s the stock on SKU X” and then fails, with no built-in fallback, the moment a workflow tries to place an order, adjust stock, or edit a customer record.
Scoring Saleor’s modernity: what’s current and what’s quietly dated
Saleor’s main branch pyproject.toml (opens in a new tab) pins Python to >=3.12,<3.13 — current, not legacy, and consistent with a project tracking upstream Python releases closely rather than lagging several majors behind.
The license is confirmed BSD-3-Clause (opens in a new tab), with no field-of-use restriction — a meaningfully different position from SSPL-style licenses that block certain commercial or hosted uses, and worth weighting higher on an “open” axis than a platform that calls itself open source while carrying that kind of restriction.
Activity signals are healthy: the saleor/saleor repository (opens in a new tab) shows 23.1k GitHub stars and 6.1k forks. Funding is a weaker but relevant signal — an $8M seed extension (opens in a new tab) closed in February 2024, led by Target Global with Zalando, Cherry Ventures, SNR and TQ Ventures, on top of an earlier $2.5M seed round in 2021 (opens in a new tab) — roughly $10.5M disclosed total. Hold this one at medium confidence: disclosed funding does not tell you current burn rate.
Now the counter-signal. The saleor-platform reference docker-compose bundles postgres:15-alpine, while this review’s host database is PostgreSQL 17.5. A two-major-version gap in a reference stack that new teams are likely to copy verbatim is worth checking before you trust it as current.
docker exec <saleor-core-container> python --version
docker exec <saleor-platform-db-container> psql -U saleor -c "SELECT version();"Expected output:
Modernity score: 7/10. Points for a current Python floor, an unrestricted BSD-3-Clause license and sustained GitHub activity. Points deducted for a reference Postgres image two major versions behind the current release line — exactly the kind of gap a team copies into production without noticing.
Production concern: nothing throttles request bursts outside the free tier
The only rate limit Saleor documents anywhere is on the free tier: 120 requests per minute (opens in a new tab) on Sandbox, with HTTP 429 returned once you cross it. That number does not appear in the Select, Volume or Enterprise documentation, and it does not apply to self-hosted deployments either.
Production Cloud and self-hosted Saleor have no request-rate limiting from Saleor itself. The only built-in production protection is the per-query GraphQL cost ceiling covered earlier — extensions.cost limits how complex a single query can be, not how many requests per second hit the endpoint.
Saleor’s own advisory history says why that gap matters rather than leaving it theoretical. On 8 April 2026 the project published two High-severity advisories in this exact area: resource exhaustion in GraphQL queries (opens in a new tab) and denial of service via unbounded GraphQL query batching (opens in a new tab). Both were patched. But the class of problem is the one an absent rate limit leaves you exposed to, and the mitigation above the free tier is yours to build.
Two more advisories landed on 27 July 2026, the same day 3.23.22 shipped: an account pre-hijacking vulnerability via unverified anonymous order merge (opens in a new tab), rated High, and an authorization bypass on selected GraphQL paths for anonymous users (opens in a new tab), rated Medium. The version this review targets is itself a security release, which is worth knowing before you pin a tag and stop watching.
The encouraging half of that record is how the fixes ship. Each advisory was patched across three maintained lines at once — 3.23.22, 3.22.63 and 3.21.67 all on the same day — so staying patched does not force a minor-version upgrade. For a platform whose upgrade path is otherwise a real project, that backporting discipline is a genuine operational advantage.
for i in $(seq 1 130); do
curl -s -o /dev/null -w "%{http_code}\n" \
https://<sandbox-instance>.saleor.cloud/graphql/ \
-H "Content-Type: application/json" \
-d '{"query":"{ shop { name } }"}'
doneExpected output:
sequenceDiagram
participant Client as Burst client
participant Sandbox as Sandbox tier
participant Prod as Production / self-hosted
Client->>Sandbox: 130 requests in under 60s
Sandbox-->>Client: ~120x HTTP 200, then HTTP 429
Client->>Prod: same 130 requests in under 60s
Prod-->>Client: 130x HTTP 200, no throttle
This is the exact risk this review set out to test: automated or agent-driven traffic bursts have nothing built in to slow them down once you leave the free tier. Mitigation is your responsibility, not the platform’s — rate limiting belongs at an API gateway, WAF, or reverse proxy sitting in front of Saleor.
Five questions to answer in a Saleor proof of concept before you commit
Run these five checks against a trial instance before you commit, rather than taking any claim above on trust.
Q1. Run your actual catalogue’s typical queries against a trial channel and read the extensions.cost value on each response. Compare it to the cost ceiling before finalising a data model that assumes deep nesting is free.
Q2. Map your real currency and region matrix to Saleor channels (opens in a new tab) one-to-one by currency, not by region name, and count how many channels that actually produces. If the number surprises you, it changes your pricing-sync workload.
Q3. Model GMV overage at 2x and 5x your current or projected volume against both Select ($1,599/month, $200,000 GMV ceiling, 0.8% overage) and Volume ($3,999/month, $1,000,000 GMV ceiling, 0.4% overage). Use your peak month, not your average.
Q4. Test whether your AI-agent use cases ship on the read-only MCP server as it exists today, or whether the workflow needs a write path Saleor does not provide yet.
Q5. Decide, on paper, who owns rate limiting and abuse protection in front of production. Saleor provides none outside its free Sandbox tier, and that decision needs an owner before launch, not after an incident.
The standing recommendation: shortlist Saleor for GraphQL-first, multi-channel, read-heavy agent workloads. Do not shortlist it expecting a shipped write-capable agent layer, or a single channel that serves multiple currencies — neither exists yet.
Limitations
This review covers Saleor Core 3.23.22 and the documented shape of Saleor Cloud pricing, MCP integration and webhook signing at research time. It does not include a load test against a production-tier Cloud instance, and the rate-limit, query-cost and version-check figures marked as pending above need to be captured against a live instance before publication.
It does not evaluate individual Saleor Apps, tax-engine integrations, or checkout and payment-provider specifics, all of which affect a real implementation’s cost and timeline beyond what is scored here.
Funding and headcount figures are a runway signal only, held at medium confidence, and should not be read as a guarantee of continued investment.
Pricing figures reflect saleor.io/pricing (opens in a new tab) at research time; Cloud vendors revise tier ceilings and overage rates without much notice, so confirm current numbers before budgeting against them.