E-Commerce Platforms & Shop Systems
Saleor
Provenance unknown Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by Saleor Commerce · saleor.io
Report an error on this page Is this your product? →
Link to this page
Add ?theme=dark to the image address for dark backgrounds.
The badge shows the category and the month of the latest evaluation, and EU-Made where
that is the product’s provenance. It never shows a score.
Saleor at a glance
- Vendor
- Saleor Commerce
- Headquarters
- Not stated on the vendor’s pages as of 13 Oct 2026
- Data hosting
- Not stated on the vendor’s pages as of 13 Oct 2026
- Free plan
- Not stated on the vendor’s pages as of 13 Oct 2026
- Panel verdict
- The AI panel rates Saleor 2.5/5, the mean of 6 judges. Saleor is an open-source, headless commerce platform whose strength is extensibility, where scores cluster at 8–9, resting on a GraphQL API, 160-plus webhooks including synchronous ones, 45-plus dashboard mount points, and mostly forkable, self-hostable apps. how scores are made
- As of
- Vendor pages captured 13 Oct 2026; evaluated by the panel 15 Oct 2026. all sources
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Saleor is an open-source, headless commerce platform whose strength is extensibility, where scores cluster at 8–9, resting on a GraphQL API, 160-plus webhooks including synchronous ones, 45-plus dashboard mount points, and mostly forkable, self-hostable apps. Order operations score 6–7: multi-warehouse split shipments, approval flows, returns and replacements with automatic draft orders, and partial refunds including shipping costs are all documented, though we found no public information on carrier label printing or ERP and accounting interfaces. The weak flank is sovereignty, scored 0–1, with no public information on data residency, contracting entity jurisdiction, ownership or subprocessors, and a managed cloud offering that names no location. Catalog and checkout scores sit at a flat 4: the variant model is documented, but we found no public information on payment methods, guest checkout or bundles behind the named Checkout API. Tax and legal spreads 3–4 on a real VAT framework, unevidenced on VAT-ID validation, OSS reporting and e-invoicing. Data control and exit ranges 5–7, split between structural open-source exit and export documentation covering products only. We found no public information on managed-cloud prices.
Speaks for it
- Extensibility scores cluster at 8–9 on an open-source core with over 21.8k GitHub stars, 160-plus webhooks including synchronous ones, and 45-plus dashboard mount points
- Fulfilment is documented in depth, covering multi-warehouse split shipments, approval flows, returns and replacements with automatic draft orders, and partial refunds including shipping costs
- Tax is genuinely modelled, with tax classes defining rates per country assignable to products, product types and shipping methods, plus per-channel gross/net entry and display
- Exit is structural rather than promised, as the open-source core and a majority of apps can be forked and self-hosted
- Product export runs as an asynchronous job in CSV or XLSX with selectable fields, attributes and per-warehouse stock columns
Held against it
- Sovereignty scores sit at 0–1, with no public information on data residency, contracting entity jurisdiction, ownership or any subprocessor
- Catalog and checkout scores cluster at 4, and we found no public information on payment methods, guest checkout, bundles or promotion rules
- Tax and legal scores top out at 4, with no public information on VAT-ID validation, reverse charge, OSS reporting or e-invoicing
- The documented export surface covers products only, with no public information on customer or order-history export, deletion, or migration paths
- We found no public information on carrier integrations with label printing or on maintained ERP and accounting interfaces
Best for
- You have an in-house development team and want a headless, open-source platform you can fork, self-host and extend, where extensibility scores cluster at 8–9
- You run multi-warehouse operations and need split shipments, approval flows and returns with automatic draft orders documented out of the box
- You want exit to be structural, with an open-source core, forkable apps and a documented CSV or XLSX product export
- You build bespoke storefronts and want configuration version-controlled through a CLI that syncs to a repository
Avoid if
- You must name hosting location, contracting entity and subprocessors before signing — sovereignty scores sit at 0–1 with no public information on any of them
- You sell B2B across the EU and need VAT-ID validation with reverse charge, OSS reporting or e-invoicing evidenced — ask the vendor: the public pages we read do not show it
- Your shop depends on invoice or direct debit payments at launch — we found no public information on payment methods, only a named Checkout API
- Your back office runs on carrier label printing and maintained ERP or accounting interfaces — we found no public information on these
The scores
| Criterion | Panel median |
|---|---|
| Catalogue & checkout | 2 of 5 |
| Tax & German legal correctness | 2 of 5 |
| Extensibility & developer surface | 4 of 5 |
| Order operations & back office | 3 of 5 |
| Data ownership & exit | 3 of 5 |
| European sovereignty | 0.5 of 5 |
Catalogue & checkout
Show reasoningHide reasoning
How this is scored
Products, variants, pricing rules and the path to payment — the part that either converts or does not.
0 — Flat product list with one price and no variants; checkout is a form and one payment method.
3 — Variants and categories with a standard checkout and two or three payment methods, but no bundles, no tiered pricing and no guest checkout worth the name.
5 — Full variant matrix, product bundles, tiered and customer-group pricing, guest checkout, and the payment methods a German shop needs including invoice and direct debit.
8 — Configurable products, per-channel pricing, promotions and vouchers with rules, a checkout that can be customised without a rebuild, and payment via the major providers plus buy-now-pay-later where offered.
10 — Merchandising and checkout are the product: rule-driven pricing and promotions, A/B-testable checkout, multi-currency and multi-language as standard, and conversion features (abandoned cart, one-page checkout) shipped rather than bolted on.
The Merchant
Good catalogue bones — variants with attributes, per-channel listings, translations, and sale and discount price fields — but the conversion path is unproven: I found no public information on payment methods at all, let alone invoice and direct debit for German shoppers, and nothing on guest checkout, bundles, tiered pricing or promotion rules. 1 2 3
The B2B Seller
Variants, channel-scoped prices and sale pricing with prior-price display are documented, and a checkout API exists — but I found no public information on payment methods, guest checkout, bundles, or tiered and customer-group pricing, which is precisely what a trade buyer needs before committing. 1 2 3
The Developer
The variant model is the strong part: variants with attribute matrices, channel-scoped pricing, sale and prior-price fields, and per-language translations, all served by a headless checkout API. But we found no public information on payment methods, guest checkout, bundles or promotion rules, so the conversion half of the criterion rests on unevidenced ground. 1 2 3
The Operations Lead
Variants are real and well documented — attributes, per-channel listings, prior-price and discount handling, translations — and a checkout API is named on the vendor page. But we found no public information on bundles, tiered or customer-group pricing, guest checkout, or any payment method, let alone invoice or direct debit, so the path to payment is barely evidenced. 1 2 3
The Data Protection Officer
The documentation shows a full variant model with attributes, per-channel price listings and discount fields, plus an advertised checkout API. We found no public information on payment methods, guest checkout, bundles or promotion rules — the conversion machinery a German shop needs — so the evidenced catalogue is strong but the checkout path beyond the API name is silent. 1 2 3
The Skeptic
A real variant matrix with attributes, per-channel listings, sale-price fields with prior-price comparisons, and per-language translations is documented, plus a Checkout API to build against. But we found no public information on payment methods — nothing on invoice or direct debit a German shop needs — nor on guest checkout, bundles, or tiered pricing. 1 2 3 5
Tax & German legal correctness
Show reasoningHide reasoning
How this is scored
VAT determination, OSS, B2B reverse charge, and the checkout requirements German law actually imposes — judged on what the platform does, not on a plugin someone could buy.
0 — A single VAT rate applied everywhere; no B2B handling, no country logic, no legal-text handling in checkout.
3 — Per-country VAT rates configurable by hand, net prices for B2B possible with effort, and legal texts as free-form pages.
5 — Automatic VAT by destination and customer type, VAT-ID validation with reverse charge, gross and net display per customer group, and the mandatory checkout elements (order button wording, withdrawal policy, price indications) handled.
8 — OSS thresholds tracked and reported, correct invoicing per case including reverse-charge notes, small-business and third-country handling, and e-invoicing (XRechnung/ZUGFeRD) for B2B orders.
10 — Tax and legal correctness are maintained by the vendor rather than the merchant: rates and thresholds updated as the law moves, OSS reporting produced, every invoice case correct out of the box, and documented conformity a lawyer could review.
The Merchant
Tax is a configurable framework: per-country rates through tax classes, channel-scoped configuration, gross or net price entry and display, and a choice of flat rates or a tax app. I found no public information on VAT-ID validation with reverse charge, OSS reporting, e-invoicing, or the German checkout legal texts, so the merchant or an app carries that weight rather than the vendor. 4 5
The B2B Seller
Tax classes carry named rates per country with country-specific exceptions, gross/net display and gross price entry are switchable, shipping tax can be weighted, and calculation can be delegated to a tax app per channel — a real VAT engine. I found no public information on VAT-ID validation, reverse charge, OSS reporting, e-invoicing or the German checkout legal texts, and net display is documented per channel rather than per customer group. 4 5
The Developer
Tax is genuinely modelled — per-channel tax configuration choosing between flat rates and a delegated tax app, tax classes with rates per country assignable to product types and shipping methods, country-specific exceptions, and flags for gross entry and gross display. We found no public information on VAT-ID validation, reverse charge, OSS handling, e-invoicing formats or the checkout elements German law requires, so the German-specific weight of this criterion is unevidenced. 4 5
The Operations Lead
Tax classes with per-country rates, channel-scoped tax configuration, gross/net display and prices entered with tax add up to a VAT model the merchant configures by hand, with calculation delegated to a flat-rates-or-tax-app strategy and no tax app named. We found no public information on VAT-ID validation with reverse charge, OSS reporting, e-invoicing, or the checkout elements German law imposes. 4 5
The Data Protection Officer
Tax classes with per-country rates assignable to products, product types and shipping methods, channel-level tax configuration, gross/net display options and country-specific exceptions are all documented, which sits above hand-configured flat rates. We found no public information on VAT-ID validation with reverse charge, OSS reporting, e-invoicing formats, the checkout elements German law mandates, or anything indicating the vendor maintains rates as the law moves. 4 5
The Skeptic
Tax classes define rates per country and each channel can be configured to charge taxes, enter prices gross, and display gross or net — which is hand-configured rates, not vendor-maintained correctness. We found no public information on VAT-ID validation with reverse charge, OSS reporting, e-invoicing for B2B, or the checkout elements German law imposes. The documented strategy is user-defined flat rates or a tax app, so the merchant carries the legal risk. 4 5
Extensibility & developer surface
Show reasoningHide reasoning
How this is scored
Themes, apps, APIs and headless — whether the shop can be shaped to the business, and at what cost in lock-in.
0 — Fixed templates, no app ecosystem, no API.
3 — Theme editing within limits and a small app store; a read-mostly API and no local development story.
5 — Custom themes with a template language, an app or plugin ecosystem, a documented REST API, and webhooks for the core order events.
8 — Full storefront API for headless builds, an extension framework with its own lifecycle, staging environments, version control for themes, and documented rate limits.
10 — A platform a team can own: headless-first APIs, open-source or source-available core, plugin architecture with a real dependency model, local development and CI supported, and upgrade paths that do not orphan customisations.
The Merchant
This is the criterion that decides a bespoke checkout for me: an open-source core with 21.8k stars, a GraphQL API, 160-plus webhooks including synchronous ones for overriding flows, tech-agnostic and forkable apps, 45-plus dashboard mount points, plus sandboxes and a CLI that syncs configuration to a repository. I found no public information on documented rate limits or a supported local development and CI story, which keeps it off the top step. 1 6 7
The B2B Seller
An open-source core, a documented GraphQL surface, over 160 webhooks including synchronous ones for flow control, dashboard extensions across 45-plus mount points, and cloud sandboxes and snapshots give a development team something it can own. I found no public information on documented rate limits, which is what keeps this short of the very top. 1 6 7
The Developer
This is where I would stake five years: an open-source core, headless-first GraphQL, an app framework with permissions and its own install, deactivate and delete lifecycle, 160-plus webhooks including synchronous ones, and a CLI that syncs configuration into a repository — version control by design rather than a theme editor. What the captured pages do not show is a dependency model between extensions, documented rate limits, or explicit local-development and CI guidance, which is what holds me below full marks. 1 6 7
The Operations Lead
Open-source core with a headless GraphQL API, an app framework with its own install, deactivate and delete lifecycle, most apps forkable and self-hostable, 160+ webhooks including synchronous ones, and cloud sandboxes and snapshots for staging. We found no public information on documented rate limits or upgrade paths for customisations, which is all that keeps this off the top. 1 2 6 7
The Data Protection Officer
This is where the platform earns its keep: an open-source core, a GraphQL API, 160-plus webhooks including synchronous events for extending flows, 45-plus dashboard mount points, and apps that are mostly open source and can be forked onto the merchant's own infrastructure. Sandboxes and snapshots give a staging story, though we found no public information on documented rate limits or upgrade guarantees for customisations. 1 6 7
The Skeptic
A headless Checkout API, a GraphQL API, 160-plus webhooks including synchronous delegation, 45-plus dashboard mount points, and a majority-open-source app ecosystem the merchant can fork and self-host. The core is open source with 21.8k GitHub stars and sandboxes and snapshots are offered, though we found no public information on documented rate limits or a local development and CI story. 1 6 7
Order operations & back office
Show reasoningHide reasoning
How this is scored
What happens after checkout: order management, stock, returns, shipping, and the link to ERP or accounting.
0 — An order list and an email; stock is a number nobody trusts, returns are manual.
3 — Order statuses and basic stock, one shipping integration, and returns handled by hand.
5 — Order workflow with partial shipments, multi-warehouse stock, named carrier integrations with label printing, and a returns process in the system.
8 — Multi-channel order intake, automated fulfilment routing, supplier and dropshipping flows, and maintained interfaces to named ERP and accounting systems.
10 — The shop is the front of an operation: real-time stock across channels and warehouses, returns and refunds fully worked including partials, ERP integration the vendor maintains, and operational reporting a merchant runs the business from.
The Merchant
The machinery after checkout is real: split and partial fulfilments across multiple warehouses, warehouse suggestions, tracked stock with external sync mutations, and returns, replacements and refunds including shipping costs all handled in the system. But I found no public information on carrier integrations or label printing, ERP or accounting interfaces, or dropshipping flows — my warehouse team would still be wiring the shipping side by hand. 2 8 9
The B2B Seller
Partial fulfilments across multiple warehouses, an approval flow, returns and replacements with automatic draft orders, and partial refunds with optional shipping costs are all worked through documented mutations and webhooks — the hard parts after checkout are genuinely built. I found no public information on carrier integrations with label printing, or on maintained interfaces to named ERP and accounting systems, which is where my back office lives or dies. 8 9
The Developer
Post-checkout is deep: multiple fulfillments per order with split shipments across warehouses, approval flows, tracking-number updates, and a returns machinery covering returns, replacements with automatically created draft orders, and refunds including partials and shipping costs, plus stock-sync mutations for external systems. But we found no public information on carrier integrations with label printing or maintained ERP and accounting interfaces, and those are the connections a real back office lives on. 1 8 9
The Operations Lead
This is where the evidence concentrates: multiple fulfillments per order with per-line quantities and warehouse choice — genuine partial shipments — multi-warehouse stock with allocation, restock on cancellation and warehouse suggestions, and returns, replacements and partial refunds worked all the way down to optional shipping-cost refunds and an automatic draft order for replacements. But we found no public information on carrier integrations with label printing, and none on maintained interfaces to ERP or accounting systems, which is where an operation this size lives or dies. 8 9
The Data Protection Officer
Fulfilment is deep: multi-warehouse split shipments, approval and cancellation flows with restocking, partial refunds that can include shipping costs, and returns and replacements that generate draft orders automatically. We found no public information on carrier integrations with label printing or maintained interfaces to named ERP and accounting systems, which is what the back office hinges on. 1 8 9
The Skeptic
Fulfilment is genuinely worked: multi-warehouse partial shipments, an approval flow, returns and replacements with automatic draft orders, partial refunds including shipping costs, and per-case stock behaviour with restocking on cancel. What the captured pages do not show is the physical-world paper trail — we found no public information on named carrier integrations with label printing, or on maintained interfaces to ERP and accounting systems. 8 9
Data ownership & exit
Show reasoningHide reasoning
How this is scored
Whether the catalogue, customers and order history remain the merchant's: export completeness, hosting choice, and what leaving actually costs.
0 — Export is a partial CSV; order history and customer records cannot leave intact, and hosting is the vendor's alone.
3 — CSV export of products and customers, order history partial, no self-hosting, no documented migration path.
5 — Complete export of catalogue, customers and orders via API or dump, documented deletion, and a stated data-return commitment.
8 — Full-fidelity export including media and order documents, self-hosting or a choice of hosting partner, and no metering that prices a migration out of reach.
10 — Ownership is structural rather than promised: open-source or source-available platform the merchant can run anywhere, database-level access, documented migration in both directions, and contractual data return.
The Merchant
Ownership looks structural: the platform is open source, most apps can be forked and self-hosted, and product export covers CSV or XLSX with selectable fields, attributes and warehouse stock via an asynchronous job. The captured pages document only the product export though — I found no public information on exporting customers and order history, documented deletion, or a migration path. 1 10 11
The B2B Seller
Product export is thorough — selectable fields, scopes, warehouse stock columns, CSV or XLSX — and the platform is open source with the majority of apps forkable and self-hostable, so a merchant can run the shop on their own infrastructure. I found no public information on customer and order export completeness, media and document export, or a documented deletion and data-return commitment. 1 6 10 11
The Developer
The open-source core and forkable, self-hostable apps make ownership structural rather than promised, and product export is real — CSV or XLSX, all or filtered, field-selectable, with attributes and per-warehouse stock columns. But the documented export surface covers products only; we found no public information on customer or order-history export, documented deletion, or a stated migration path, and that is what leaving actually costs. 1 6 10 11
The Operations Lead
Product export is properly built — selectable fields, attributes, warehouse stock columns, CSV or XLSX, asynchronous with status polling and an emailed download link — and the open-source, self-hostable core makes exit structural rather than promised. We found no public information on exporting customers or order history, on deletion, or on a documented migration path in either direction. 1 6 10 11
The Data Protection Officer
Product export is real and configurable — selectable fields, warehouse stock columns, asynchronous delivery with a downloadable URL — and the open-source core with forkable apps makes running the shop on one's own infrastructure a genuine exit option. We found no public information on exporting customer records and order history, on a documented deletion process that executes against order data, or on any contractual data-return commitment. 1 6 10 11
The Skeptic
Products export with selectable fields, attributes and per-warehouse stock, delivered asynchronously with a download link, and the platform is open source with apps that can be forked and self-hosted — exit here is structural rather than promised. But the captured export documentation covers products only, and we found no public information on complete customer and order-history export, documented deletion, or a migration path in either direction. I always read the exit clause first, and this one leaves the order history on the table. 1 6 10 11
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Where customer and order data live, who the contracting entity is, and which subprocessors sit in the checkout path. Independently sourced by the sovereignty pipeline.
0 — Non-EU vendor and contracting entity, hosting unstated or non-EU, subprocessors unnamed.
3 — EU hosting offered as an option while the contracting entity is non-EU, or the subprocessor list is absent.
5 — EU hosting as standard and an EU contracting entity, but parts of the chain — CDN, analytics, payment routing, support tooling — are non-EU without an explained safeguard.
8 — EU hosting on named infrastructure, EU contracting entity, complete subprocessor list published, any non-EU processing named with its legal basis.
10 — Sovereign end to end and evidenced: vendor, entity, hosting and every subprocessor European, certification published, and a self-hosted option that puts the shop entirely under the merchant's control.
The Merchant
The only hosting signal is a managed cloud offering with no location stated. I found no public information on where customer and order data live, on the contracting entity, ownership, or any subprocessor list — for a German checkout that chain has to be nameable before I would put it live. 1
The B2B Seller
The captured pages present a managed cloud offering with no statement of contracting entity, hosting region or subprocessors, and I found no public information on any of these points; nothing in the captured material evidences EU residency, an EU entity or a safeguard anywhere in the processing chain. 1
The Developer
The captured pages state nothing about the contracting entity, ownership, hosting location or subprocessors, and every sovereignty attribute came back unknown. The only lever evidenced is that the open-source core and its apps can be forked and self-hosted, which is a path to control the merchant builds rather than a published posture. 1 6
The Operations Lead
I found no public information on the contracting entity, ownership, where customer and order data is hosted, or any subprocessor list, and the managed cloud offering names no hosting location. Self-hosting the open-source core is the one evidenced route to keeping the whole stack under a merchant's own roof. 1 6
The Data Protection Officer
Every sovereignty attribute came back unknown — contracting entity jurisdiction, ownership, data residency and subprocessor exposure — and the managed cloud offering is described without naming a location. We found no public information on where customer and order data are processed or which third parties sit in the checkout path, including CDN and analytics, which is the lowest band of evidence. 1
The Skeptic
We found no public information on where customer and order data are hosted, the contracting entity's jurisdiction, ownership, or a single subprocessor; the only hosting statement is a managed cloud offering — "You build. We infra." — with no location named. Unnamed subprocessors in the checkout path are exactly the part of the invoice and the liability I cannot audit. 1
Pricing transparency
not rated — the vendor publishes no price
Show reasoningHide reasoning
How this is scored
Whether a merchant can compute the real annual cost — licence, transaction fees, apps, hosting — from public pages alone. The category where the headline price is least often the invoice.
0 — No public prices at all; every tier is a sales conversation.
3 — A monthly headline exists, but transaction fees, mandatory apps or hosting costs are unstated — the invoice is unknowable from the page.
5 — Tier prices public with billing period stated and transaction fees given, but at least one commonly needed piece (a required app, hosting, payment gateway rate) is unpriced.
8 — Every tier priced publicly including transaction or revenue-share rates, order or GMV limits, and the cost of the extensions most shops need; VAT treatment and minimum term stated.
10 — Complete price computability: annual cost derivable for a given order volume and GMV including licence, transaction fees, hosting and typical extensions — and for open-source platforms, an honest statement that the licence is free and where the money actually goes.
The Merchant
The open-source repository makes the licence itself free, which I will credit. Beyond that I found no public prices at all — nothing on cloud tiers, transaction fees, support, or extensions — so the real annual cost is a sales conversation rather than a computation I can make from the pages. 1
The B2B Seller
No tier price, transaction fee or hosting cost appears on the captured pages; the only public cost fact is that the core is open source, so the licence itself carries no price. What a hosted shop pays over a year cannot be computed from what the vendor publishes. 1
The Developer
The open-source licence makes the self-hosted cost base knowable — free — and that much is public. For the managed cloud, onboarding and support we found no public prices at all; the pages describe the offering and stop there, so the annual cost of running on the vendor's infrastructure is a sales conversation. 1 6
The Operations Lead
Not one figure: we found no public information on tiers, licence costs, transaction fees, order limits or hosting prices for the managed cloud. The pages offer engineer-led onboarding and direct access to the core team instead, so a merchant cannot compute an annual cost from what is published. 1
The Data Protection Officer
The captured pages show no price for the managed cloud, for support, or for extensions; entitlements like direct access to the core team read as a sales conversation. The only cost fact evidenced is the open-source core available on GitHub, which on its own does not make an annual invoice computable. 1
The Skeptic
Not one figure appears on the captured pages: no cloud tier prices, no transaction or revenue-share rates, no order limits, no term, no app costs, no onboarding price — only marketing slogans around the managed cloud. The open-source licence at zero is the sole cost a merchant can compute; the rest of the annual invoice is a sales conversation. 1
European sovereignty — proven facts
0 of 4 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Not determined | — | uncited Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | Not determined | — | uncited Report an error |
| Subprocessors | Not determined | — | uncited Report an error |
Questions about Saleor
Is Saleor European?
Not determined: the vendor’s pages as captured do not say where Saleor is based.
Where does Saleor store data?
Not stated on the vendor’s pages as of 13 Oct 2026.
Does Saleor have a free plan?
Not stated on the vendor’s pages as of 13 Oct 2026.
What are the best alternatives to Saleor?
As of 21 Oct 2026, the panel rates JTL-Shop (3/5), Medusa (3/5) and Shopify (3/5) highest among the other 25 E-Commerce Platforms & Shop Systems products evaluated. Ratings that look equal are rounded to half stars; the order uses the unrounded rating, then the name. The highest-rated European alternative is JTL-Shop (EU-Made). Ratings are the AI panel’s opinion, formed from public evidence: how scores are made. The full list, with European products first: Saleor alternatives.
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 13 Oct 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- 8 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 1 legal fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 6 of the readings below were written against an earlier fact sheet — a fact has been corrected, added or pulled since. Until the panel next runs on this product you are reading the older judgement. Know more? Tell us
Sources (11)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor page saleor.io Checked 13 Oct 2026 Details →
- 2 Catalogue & checkout — found from sitemap docs.saleor.io Checked 13 Oct 2026 Details →
- 3 Catalogue & checkout — found from sitemap docs.saleor.io Checked 13 Oct 2026 Details →
- 4 Tax & German legal correctness — found from sitemap docs.saleor.io Checked 13 Oct 2026 Details →
- 5 Tax & German legal correctness — found from sitemap docs.saleor.io Checked 13 Oct 2026 Details →
- 6 Extensibility & developer surface — found from sitemap docs.saleor.io Checked 13 Oct 2026 Details →
- 7 Extensibility & developer surface — found from sitemap docs.saleor.io Checked 13 Oct 2026 Details →
- 8 Order operations & back office — found from sitemap docs.saleor.io Checked 13 Oct 2026 Details →
- 9 Order operations & back office — found from sitemap docs.saleor.io Checked 13 Oct 2026 Details →
- 10 Data ownership & exit — found from sitemap docs.saleor.io Checked 13 Oct 2026 Details →
- 11 Data ownership & exit — found from sitemap docs.saleor.io Checked 13 Oct 2026 Details →