Sylius vs Endora Commerce — which one to pick for B2B

Sylius is one of the best-designed things ever built in PHP commerce. Headless from day one, built on Symfony and API Platform, with an MIT-licensed core and an architecture you can genuinely test. The domain model is open: you override entities, swap services, and individual components (catalog, promotions, shipping) can be reused even outside a shop. Version 2.x moved to Symfony 7 and the native Workflow component, dropping older dependencies along the way. If you have a Symfony team, Sylius hands them a tool they feel at home in from the first day.

And this is where the difference that runs through this whole article begins. Sylius is a framework, not a finished shop. You get a foundation and a set of well-made building blocks, but the platform, and a B2B platform in particular, is something you assemble yourself or with an agency. Endora Commerce is the inverse: a ready-made B2B platform with over sixty modules as standard, deployed by configuring it to your processes. The buyer is an organization, price comes from a contract, and the request for quotation is part of the core rather than a bolted-on plugin.

There is one more thing that sets this comparison apart from the Shopify and Magento ones: in both cases the code is yours. There is no argument about lock-in, database access, or a subscription that grows with your revenue. What remains is a narrower and harder question: how much do you want to build yourself, how much finished software do you want to pay for, and where does your team’s time sit in that calculation.

The short version

If you only read three sentences: pick Sylius when you have a Symfony team and want to build a platform exactly to your own shape, because your sales model does not fit anything off the shelf. Pick Endora when you need working B2B rather than a foundation for B2B: organization hierarchies, requests for quotation, credit limits, KSeF, and Comarch should be configured, not written. If you already run Sylius in production with developers who know it, the right question is “what do we add”, not “what do we migrate to”.

What each of these platforms actually is

Sylius

Sylius is a headless commerce framework built on Symfony, Doctrine, and API Platform. The core is MIT licensed, so it costs nothing and carries no usage restrictions. Version 2.0 moved the platform to Symfony 7, replaced the old winzou state machine with the native Workflow component, and dropped SwiftMailer in favour of symfony/mailer. Version 2.1 added support for PHP 8.4 and Symfony 7.3, WCAG AA accessibility, and a refreshed admin panel. The current line is 2.2.x. The August 2026 release requires PHP 8.3 or newer and Symfony 7.4.

The distinction that matters most for this comparison is between the two editions:

• Sylius (MIT) — the free core: catalog with variants and attributes, sales channels with their own prices, currencies, and locales, promotions, shipping, payments through Payum, cart and checkout, admin panel, full API. It contains no B2B features. Buying organizations, contract price lists, wholesale quick ordering, and price negotiation have to be bought or written.
• Sylius Plus — a commercial, modular layer on top, with official support and a defined SLA. It currently has eleven modules: B2B Suite, Marketplace Suite, Advanced Multi-store, Returns Management (RMA), Multi-source Inventory, Loyalty System, RBAC, Partial Shipment, Request for Quotation (RFQ), Product Configurator, and Subscription. You buy individual modules or the whole bundle, billed monthly, annually, or as lifetime access.

Plus pricing opens with a “from €800 per year” figure, but that is an entry point rather than a rate. The actual number is an individual quote based on online revenue (GMV) and on which and how many modules you choose. There is no public table of thresholds.

The B2B Suite itself gives you: organization management (a master account with sub-accounts, shared billing data, address book, and order history), multiple price lists with individual prices and quantity tiers, wholesale quick ordering from a single screen, an Elasticsearch-based search tuned to B2B cases, multiple wishlists, order management with reordering, and import/export for PIM or ERP. The module description contains no credit limits and no buyer-side order approval path. Those have to be built.

The ecosystem has grown: the Addons Marketplace launched in 2026 collected over 500 plugins indexed from public repositories and Packagist, with listings maintained by the authors themselves.

Endora Commerce

Endora Commerce is a B2B platform written in TypeScript: a Fastify backend with MikroORM and Zod contracts, a server-rendered Next.js storefront, a React admin panel. Data in PostgreSQL, cache and queues in Redis, search in Meilisearch. Over 60 modules as standard, from catalog and price lists to KSeF, product feeds, and an AI assistant in the admin panel.

There are no editions here and no modules to buy separately. Organization hierarchies, requests for quotation, credit limits, multi-warehouse stock, returns with RMA numbering, roles and permissions, and sales channels are part of the platform rather than separate line items on an invoice.

B2C runs on the same installation and the same data model: registering a retail customer creates a single-person organization in the background, so orders, quotations, invoices, and addresses follow the same path as in B2B. B2C is enabled per sales channel.

The delivery model: you do not buy a license, you get a platform deployed to your processes, with the code in your own Git repository. The first working prototype takes four weeks, using Spec-Driven Development supported by AI. An average rollout falls roughly in the PLN 60-80k range, excluding integrations with external systems, which are quoted separately.

Performance

With Sylius this criterion has to be framed differently than with finished platforms, because the performance of Sylius is largely the performance of whatever you build on it. The framework imposes neither a caching layer, nor a storefront rendering strategy, nor a query model. A team that knows Doctrine and understands HTTP cache configuration will get very good numbers out of Sylius. A team that does not can build a shop on the same code that chokes on three hundred categories, and that will not be Sylius’s fault.

The standard 2.x storefront is Twig with Symfony UX. The headless variant with your own frontend is fully supported by API Platform, but that is a separate project: your own application, your own hosting, your own budget.

Endora renders its storefront server-side in Next.js, with Core Web Vitals targets written directly into the platform requirements (LCP under 2.5 s, INP under 200 ms, CLS under 0.1) and search under 200 ms at the 95th percentile. A concrete number on scale: generating a product feed for 100,000 products produces a 38 MB file with peak memory usage under 20 MB, because serialization is streamed. The demo runs on a catalog of over 120k SKUs.

The practical difference concerns individual pricing. In B2B every company sees its own price, so full-page caching stops being something you can base performance on. Endora computes price through the pricing engine on every request: from a group price list, an individual contract, a quantity tier, and a time window, with deterministic resolution of overlapping rules. In Sylius the same scenario is buildable and plenty of teams pull it off, but you are the one designing where the cacheability boundary lies.

A caveat in both directions: Sylius has years of European deployments behind it and well-mapped Symfony and Doctrine bottlenecks, and its performance is steerable because everything sits on your side. Endora’s numbers are architectural targets confirmed by tests and by the scale of the demo, not a decade of production peaks.

Cost of rollout and ownership

Here you have to count something that license comparisons never show: the cost of building what the other side has already configured.

The Sylius core itself costs nothing, and that is a real advantage. But the core has no B2B features. That leaves three routes, each with a price: buy Sylius Plus modules (B2B Suite plus RFQ is already two line items, and you will not find credit limits or order approval in either), buy plugins from third-party vendors, or write the code. In practice most B2B builds on Sylius mix all three.

On top of that comes a list of things nobody maintains for you in the Polish market. There is no ready, supported KSeF plugin for Sylius. The official Invoicing Plugin generates PDF invoices, not FA(3) documents submitted to the Ministry of Finance system. Integrations with Comarch ERP Optima or Subiekt GT are not available as Sylius Plus modules either. These are separate development projects, each with its own schedule and its own maintenance.

An average Endora Commerce rollout falls roughly in the PLN 60-80k range. That covers the workshop, configuring the platform to your processes, and the production launch, with no license, no per-seat fees, and no revenue share. The figure is a starting point rather than a ceiling, and it usually excludes integrations with external systems, which are quoted separately once the workshop has settled what should sync and in which direction.

A caveat on the Sylius side: if you have your own Symfony team, part of this bill disappears, because you are spending the time of people you employ anyway. For a company with an in-house PHP department, “we will build it ourselves on Sylius” is often more sensible than buying a finished platform nobody inside knows.

A caveat on the Endora side: no license fees does not mean the platform is free. The PLN 60-80k is a real expense, integrations are added on top, and development after launch costs too. The difference is that the budget goes into developing your platform and does not grow automatically with your revenue.

Ease of extending the platform

This criterion is best tested with a single question: how long does it take to add an “in production” order status and a “contract number” field on an order?

In Sylius both are developer tasks. The status: configuring transitions in the Symfony Workflow component plus code listening on those transitions, tests, and a deployment. The field: extending the Doctrine entity, a database migration, a form type in the admin panel, a template, and possibly exposing it in the API. None of this is hard for someone who knows Symfony, and that is precisely Sylius’s strength. But it is still a code change, a deployment, and a line in the backlog.

In Endora both are done in the admin panel. Order statuses and the transitions between them are configurable, with a business event attachable to every transition. Custom fields are added to orders, organizations, customers, categories, products, and quotations as data, with no database migration and no code deployment.

That last row matters and it works in Sylius’s favour. Sylius lets you remodel the domain from zero. If your sales require a product that cannot be described as a variant with a price, you simply write your own entity and your own engine. Endora gives you modules and contracts, not a blank page. For most companies that is an advantage, because a blank page has a price. For a company with a genuinely unusual model it is a constraint.

Sylius also has an advantage that cannot be argued away: the talent pool. Symfony developers can be hired or contracted in any decent-sized city, the documentation is extensive and public, and an agency can be replaced without rewriting the platform. Endora gives you the code, but a team that knows this platform from the inside will not turn up on your first job posting. It helps that the code is ordinary TypeScript with Zod contracts rather than a proprietary framework, but it does not remove the risk.

One thing runs the other way, and Sylius has no equivalent: the Endora admin panel ships with an AI assistant. You open the command palette and describe in plain language what should happen. The assistant shows a change plan and executes it after your confirmation, within your permissions and with an entry in the audit log.

There is a number behind that, because “fast” on its own means nothing: a less complex module takes 1-3 days in Endora, a larger one up to a week. That excludes integrations with an ERP, WMS, CRM, PIM or OMS: those are always heavily bespoke, and writing one takes up to two weeks. This is not an advantage over open code as such, because there you can write whatever you want too. It is an advantage of the starting point: you add a module to a working B2B platform instead of first building the thing that is meant to be extended.

Integrations with external systems

In B2B this is usually the deciding criterion, because the platform is almost never the source of truth: the ERP is, with a CRM, a WMS, and increasingly an OMS alongside it.

Where Sylius wins

The PHP ecosystem and a mature API. Sylius runs on API Platform, so you get REST with OpenAPI documentation from day one, along with filtering, pagination, and resource versioning. On top of that sits all of Symfony: Messenger for queues and events, HttpClient, console commands, and schedulers, plus everything on Packagist. If your ERP ships a PHP library, the integrator starts with composer require rather than with the protocol documentation.

The pool of implementers. There are simply a lot of people who can wire Symfony to an ERP, in Poland included. The Addons Marketplace with over 500 plugins improves the odds that someone has already walked part of the road.

Where Endora wins

A shorter list of ready-made integrations, but a stronger contract and Polish requirements built in.

• Comarch ERP Optima and Subiekt GT, adapters as standard: product records, stock, prices, and sales documents.
• KSeF in the platform core: invoices and corrections in the FA(3) format sent through a durable queue, the KSeF number on the document, the confirmation receipt available for download, and a verification QR code on the PDF. On Sylius this is custom work today, and with KSeF mandatory in 2026 that is not a detail.
• A partner API with living OpenAPI: the document is generated from the contracts in code, so the integrator never works from an outdated PDF.
• An API key scoped to an organization and a channel: the integration sees exactly that company’s prices, limits, and assortment, and can do no more than its own buyer. There is no parameter that bypasses the rules.
• Idempotent orders: a repeated request returns the same order, never a second one. This holds for concurrent repeats too.
• Webhooks signed with HMAC-SHA-256, up to eight attempts with increasing intervals, and a separate view of failed deliveries with manual retry.
• Bulk pricing: one request prices up to 200 line items for a specific organization, guaranteed to match the cart to the last cent.
• Credentials encrypted with AES-256-GCM, tested on save, masked on read, and redacted in the audit log.

Endora’s integration layer is generic: there is no list of “supported ERPs”, there is a documented contract. Any ERP, CRM, WMS, or OMS plugs in as an adapter module. The same route produced the Stripe, PayU, and tpay adapters.

The most important difference, though, is what the contract knows about your business. Endora’s API understands organizations: a key scoped to a company sees that company’s price list, its credit limit, and its assortment. In Sylius the API is neutral and very well designed, but commercial permissions in an organization context are something you add yourself, because the core has no organizations.

B2B: where Endora Commerce genuinely stands out

Let me start with what there is no point hiding: Sylius Plus has a serious B2B offering, not a fig leaf. The B2B Suite provides organizations, multiple price lists with quantity tiers, wholesale quick ordering, and search tuned to B2B catalogs. A separate RFQ module handles price negotiation from the cart. Add RBAC, multi-source inventory with stock routing, RMA returns, partial shipments, and multi-store. This set will genuinely run business-to-business sales.

Two things need saying alongside it. First, these are paid modules bought separately, and underneath them there is still a framework somebody has to take to production. Second, a handful of mechanisms are missing from the offering entirely.

1. Organization hierarchy as a tree with inherited terms. The B2B Suite models a company as a master account with sub-accounts sharing billing data and history, which is a flat structure. In Endora headquarters and branches form a tree: order visibility flows downwards, while the price list and the credit limit are inherited from the nearest ancestor. A company with twenty branches does not require twenty parallel configurations.

2. The credit limit as a risk-control tool. The B2B Suite description contains no credit limits. Endora grants a limit to an organization, reserves it atomically at order placement, and releases it once the invoice is paid or the order cancelled, filtering the available payment methods once the limit is used up. That is the difference between payment terms and actual exposure control.

3. Buyer-side order approval. If your buyer has an internal procedure requiring a manager’s sign-off, in Sylius that has to be written. Endora has cart approval enabled per organization, with a full submission path and a decision with a stated reason.

4. Requests for quotation as a full loop, plus a catalog without prices. The RFQ module in Sylius Plus handles negotiation from the cart. Endora goes further: the salesperson quotes with a delivery date and a validity period, both sides can amend the terms, and an accepted quote turns into an order without re-entering the line items. On top of that comes the none price display mode, which hides every pricing element and routes purchase intent into a quotation, for assortment that is never sold from a price list on principle.

5. Changes the business makes, not a developer. Configurable order statuses with a business event on every transition, and custom fields on orders, organizations, customers, categories, products, and quotations added as data, with no migration and no deployment. In Sylius every such change goes through the repository and a release.

6. Wholesale reality in one package. Packaging units (pallets, cartons, packs) with unit conversion, cart import from CSV or Excel with variant matching, search by SKU and attributes, one-click purchase, shopping lists, a product comparison tool with PDF export, returns with RMA numbering and correction invoices, multi-warehouse stock with reservations and backorders. In Sylius some of this comes as separate Plus modules and some is your own work.

There is also something that never shows up on a feature list: every sensitive operation lands in the audit log with the state before and after the change, and a salesperson can step into a customer’s context and see the prices through their eyes, with a visible banner and a log entry.

Where Sylius has the edge within B2B itself: the breadth of its module catalog. Marketplace Suite lets you run multi-vendor sales with payment splitting, Product Configurator handles products assembled by the customer with real-time pricing, Subscription covers subscription sales, and Loyalty System covers loyalty programmes. Endora has none of those four. If any of them is a hard requirement for you, Sylius is closer to a finished solution. That is an advantage no architectural argument can wave away.

When Sylius will be the better choice

1. You have a Symfony team. This is the strongest argument in the whole article. A PHP team starts on Sylius from day one, with no new platform to learn, and already knows every tool around it: Doctrine, Messenger, testing, deployments. Competence you already have is worth more than finished modules you cannot maintain.

2. Your sales model does not fit anything off the shelf. A product that cannot be described as a variant with a price, pricing from a configurator, services sold alongside goods. Sylius lets you remodel the domain from the ground up and does not pretend to know better.

3. You need a marketplace, subscriptions, a product configurator, or a loyalty programme. Those are ready Sylius Plus modules, and Endora does not have them.

4. Vendor replaceability matters to you. The Symfony agency market is deep, running a tender for the next implementer is realistic, and an MIT core ties you to nobody.

5. You are building something that is not only a shop. Sylius components can be used inside a larger Symfony application: a portal, an order handling system, an internal tool. A rare but real scenario.

6. You already run Sylius in production. Replatforming without a costed business reason is one of the most expensive ways to achieve nothing. If the platform works, add the missing features.

7. Your B2B fits what the B2B Suite provides. Organizations, group price lists, quantity tiers, quick ordering, and good search. If that is the whole list and you have someone to assemble it, there is no reason to look further.

When Endora Commerce will be the better choice

1. You need working B2B, not a foundation for B2B. If the decision has to be made this quarter and sales have to start this year, the difference between “we configure” and “we build” is a difference in the schedule, not in philosophy.

2. Sales go through negotiation. Quotations are the main path, part of the assortment has no visible price at all, and an accepted quote should turn into an order without re-entering the line items.

3. Your customer structure is a tree, not a list. Capital groups, branches inheriting price lists and limits from headquarters, order visibility flowing downwards. A flat master account with sub-accounts will not model that.

4. The credit limit is a tool for you, not a declaration. Reservation at order placement, release once the invoice is paid, payment methods filtered once the limit is used up.

5. You work in Polish conditions. Comarch ERP Optima or Subiekt GT in the background, mandatory KSeF in the FA(3) format, PayU and tpay at checkout, invoices with your own numbering. All of it is native in Endora and has to be written and maintained on Sylius.

6. The budget and the deadline are fixed up front. Roughly PLN 60-80k with no license, integrations quoted separately, a prototype after four weeks. That is a different kind of predictability than a development project whose scope is settled along the way.

7. Your team works in TypeScript, not PHP. One language from the database to the interface, contracts shared between backend and frontend, an ordinary monorepo in your repository.

8. You want part of the changes made by the business, not a developer. Order statuses, custom fields, price lists, email content, and invoice templates configured in the admin panel, with no queue at the vendor.

9. You are launching several channels at once and want retail too. Storefront, marketplace, distributor portal, PWA, and POS as separate channels of one installation, with B2C on the same data model: no second system and no watering down the B2B model.

What Endora Commerce does not have

This section is here so the article can support a decision rather than merely leave you convinced.

• An extension marketplace. Sylius has the Addons Marketplace with over 500 plugins. In Endora every unusual feature is development work.
• The Symfony ecosystem. Decades of libraries, patterns, and integrators who have done it before. That is not replaced by a declaration.
• A deep talent pool. There are many times more Symfony developers than people who know Endora. It helps that the code is ordinary TypeScript with Zod contracts rather than a proprietary framework, but it does not cancel the risk.
• The modules Sylius Plus has: multi-vendor marketplace sales, subscriptions, a product configurator, and a loyalty programme.
• Complete freedom to remodel the domain. Endora gives you modules and contracts, Sylius gives you a blank page. If your model is genuinely unusual, the blank page can be cheaper.
• A decade of references at extreme scale.
• Full API integrations with marketplaces. Allegro, Amazon, and eBay are served today by downloadable feed templates, not two-way API integration.
• Upkeep bundled into a single price. Someone has to maintain the server, the backups, and the updates, exactly as with Sylius. You can run that yourself, or contract it to us or to a partner firm under an SLA.
• Multi-level purchase order approval to the extent enterprise platforms provide it.

A short checklist

Answer these questions for yourself: the answers usually line up on one side.

1. Do you have a team that knows Symfony, a team that knows TypeScript, or neither?
2. Do you want to build a platform to your own shape, or launch a finished one and adapt it by configuration?
3. Can your sales model be described as catalog, prices, and orders, or does it require its own domain?
4. Do you need credit limits, order approval, and a branch hierarchy, or are organizations and price lists enough?
5. Are KSeF, Comarch, or Subiekt hard requirements for you? And who will maintain those integrations for the next five years?
6. Are the budget and the deadline defined up front, or can the scope take shape along the way?
7. Do you need a multi-vendor marketplace, subscriptions, a product configurator, or a loyalty programme?
8. Who is meant to add a new field on an order: an administrator in the panel or a developer in the repository?

A majority of “we have a Symfony team”, “the model is unusual”, “we need a marketplace or subscriptions”, “the scope will take shape” points to Sylius. A majority of “we want finished B2B”, “limits and branch hierarchies”, “KSeF and a Polish ERP”, “the budget is fixed up front”, “an administrator should make the changes” points to Endora.

Summary

Sylius and Endora Commerce sit on the same side of one important line: the code is yours, the data is yours, and nobody counts a percentage of your revenue. They differ in what you get on day one. Sylius gives you an excellent foundation, an enormous PHP ecosystem, and complete freedom. You pay for it by having to assemble B2B from paid modules and your own code, and by KSeF, Comarch, and Subiekt staying on your plate. Endora gives you a B2B platform where organization hierarchies, quotations, credit limits, and Polish requirements are configured rather than written. You pay for it with a narrower ecosystem, the absence of four modules Sylius Plus has, and less freedom to remodel the domain.

The simplest test: if you have a Symfony team and time to build, Sylius will probably give you a better result and a smaller bill. If you need working B2B this year, work with a Polish ERP and KSeF, and your customers come with credit limits and branch structures, it is worth costing the other option.

Endora’s admin panel and storefront run online, so the quickest route is to click through the demo yourself or book a free workshop, where we will walk through your processes and systems and scope the first rollout together with its integrations.

And if that conversation ends with Sylius being the better choice, we will say so plainly. A failed rollout is not a good reference for anyone.