Guía completa de Saleor.

Saleor es una plataforma de comercio electrónico open source, headless y API-first. Está construida sobre Python y expone GraphQL como contrato principal: el dashboard de administración consume la misma API que cualquier cliente externo, lo que hace la plataforma internamente coherente.

A diferencia de las plataformas monolíticas tradicionales, Saleor no asume cómo tiene que ser tu storefront, tu búsqueda, tu OMS ni tu CMS. Provee el núcleo de comercio —catálogo, pricing, pedidos, pagos, fulfilment, multialmacén, multichannel— y deja que el resto de capas se compongan con piezas especializadas.

Este enfoque tiene una consecuencia directa: Saleor no es una alternativa a Shopify en el sentido de "otra tienda online más fácil o más potente". Es una alternativa a la idea de suite cerrada: si tu proyecto necesita componer piezas especializadas alrededor del comercio, Saleor encaja. Si tu proyecto es un catálogo estándar con operativa sencilla, probablemente te conviene una suite tradicional y Saleor será demasiada infraestructura para tu caso.

El modelo de licencia es open source (BSD-3) con una opción gestionada llamada Saleor Cloud, pensada para proyectos que quieren capacidades enterprise sin gestionar infraestructura propia. También se puede desplegar self-hosted en Kubernetes cuando hay requisitos específicos de soberanía de datos o de personalización profunda del runtime.

Composable commerce es un enfoque arquitectónico donde cada capacidad de comercio se resuelve con una pieza especializada en lugar de una suite cerrada. Catálogo en Saleor, búsqueda en Algolia o Meilisearch, PIM en Akeneo, OMS en un sistema dedicado, CMS para contenido editorial, frontend en Next.js o Astro. Cada pieza habla GraphQL o REST con las demás.

La ventaja es flexibilidad: si mañana quieres cambiar el buscador, cambias el buscador sin tocar el catálogo. Si quieres añadir un canal nuevo, el channel es una primitiva de Saleor diseñada para ello. Si una pieza deja de servirte, la sustituyes sin rehacer el resto.

El precio es complejidad de orquestación: necesitas diseñar cómo hablan las piezas entre sí, cómo se sincronizan datos, cómo se gestionan los eventos. Por eso composable no es "mejor por definición": es mejor cuando la complejidad del negocio justifica esa complejidad arquitectónica.

En Saleor, las primitivas clave de composable son: channels (dimensiones comerciales: mercados, canales, B2B vs B2C), warehouses (almacenes físicos o lógicos con stock propio), metadata (claves arbitrarias para datos custom en cualquier entidad), apps (extensiones desplegables como servicios independientes) y webhooks (eventos productivos hacia sistemas externos).

Con esas cinco primitivas y una capa de orquestación bien diseñada se pueden modelar prácticamente todos los escenarios comerciales exigentes que hemos encontrado en proyectos reales.

Saleor no trae B2B "empaquetado" como una funcionalidad cerrada a activar, al estilo Adobe Commerce B2B Suite. En su lugar, ofrece primitivas abiertas que permiten modelar cualquier escenario B2B con precisión, a cambio de un diseño arquitectónico consciente al inicio.

Las capacidades B2B típicas y cómo se modelan:

• Pricing por cliente o canal: channels + precios por channel; lógica de escalados y contratos vía app o middleware conectado al ERP.
• Cuentas de organización: empresas con varios usuarios, modeladas como grupos de customers con metadata y roles.
• Cuotes y aprobaciones: carritos persistentes, draft orders, apps de aprobación específicas.
• Catálogos privados: channels + visibility rules por cliente o grupo.
• Multialmacén: warehouses nativos con stock independiente, reglas de prioridad y split fulfillment.
• Pay-by-invoice, líneas de crédito: métodos de pago custom conectados con sistemas de gestión de cobro.

El resultado es una plataforma B2B más flexible que Adobe Commerce B2B Suite, a cambio de modelarla. Por eso los proyectos B2B sobre Saleor empiezan casi siempre con una fase de modelado explícito de cuentas, pricing y procesos antes de escribir código.

La fortaleza real de Saleor aparece cuando la capa de comercio coordina los sistemas de los que depende el negocio. ERP (SAP, Business Central, Odoo, Sage, NetSuite), CRM (Salesforce, HubSpot, Dynamics), PIM (Akeneo, Pimcore, Plytix), OMS, pasarelas de pago, operadores logísticos, buscadores especializados.

El patrón recomendado para integraciones críticas es middleware orientado a eventos: Saleor emite webhooks cuando ocurre algo (creación de pedido, cambio de stock, actualización de cliente), un servicio intermedio los procesa y orquesta las llamadas al sistema externo. Al revés, los cambios en el sistema externo se capturan (mediante polling, webhooks del ERP, o servicios de streaming) y se propagan a Saleor vía GraphQL.

Este patrón tiene tres ventajas prácticas: aísla la complejidad del sistema legacy (muchos ERPs exponen BAPIs, IDocs o SOAP) detrás de una capa moderna, permite reintento e idempotencia sin ensuciar el core de Saleor, y hace posible observar la integración como producto independiente con sus propios dashboards y alertas.

El error más frecuente en integraciones Saleor no es técnico sino de modelado: decidir qué sistema es la fuente de verdad para cada entidad. Normalmente el ERP gobierna catálogo, precios y stock; Saleor gobierna la experiencia de cliente y la captura de pedidos; el OMS gobierna fulfilment y devoluciones. Cambiar ese reparto requiere acuerdo explícito al inicio del proyecto.

Saleor Cloud es la opción gestionada por el equipo creador. Cubre infraestructura, backups, CDN, escalado automático, monitorización y soporte. Tiene diferentes tiers según volumen y SLA. Para la mayoría de proyectos medios es la opción más razonable: elimina coste operativo y te permite concentrarte en modelo y desarrollo.

Self-hosted en Kubernetes tiene sentido cuando hay requisitos específicos: soberanía de datos (ej. sector público, sanidad), personalización profunda del runtime, integración con infraestructura existente (service mesh, observabilidad propia) o control de costes a escala muy alta. Es factible pero añade carga operativa significativa: necesitas equipo o partner con experiencia Kubernetes además del experto en Saleor.

El rendimiento de Saleor es sólido. Tanto el core como GraphQL están optimizados para consultas con alto fan-out. El rendimiento real depende más del storefront (Next.js o Astro con buen caching HTTP y edge rendering) que del core de Saleor.

En coste total, un proyecto Saleor típico se reparte en tres capítulos: Saleor Cloud (o infraestructura equivalente), desarrollo e integración (el grueso), y evolución continua posterior. Para una primera versión productiva en B2B medio el rango orientativo es entre 100k y 300k euros. Proyectos enterprise con integraciones complejas escalan a 300k-600k+. Esto varía enormemente según el número de integraciones críticas y el alcance B2B.

Saleor es headless por diseño: no incluye un storefront predefinido que puedas activar. Necesitas un frontend propio que consuma su GraphQL. En la práctica, las dos opciones más frecuentes son Next.js (por defecto para la mayoría de casos, por madurez, ecosistema y talento disponible) y Astro (para proyectos con alto componente editorial o donde el rendimiento estático es crítico).

El equipo de Saleor publica un storefront de referencia en Next.js (conocido como Saleor Storefront) que sirve como punto de partida: catálogo, fichas, checkout, cuenta de cliente. En proyectos reales casi nunca se usa tal cual: el diseño, la experiencia de marca y las necesidades B2B obligan a construir un storefront propio que use el de referencia más como inspiración que como base.

La ventaja de ser headless es obvia: control completo sobre la experiencia, sin restricciones de themes propietarios. La desventaja también: tienes que construirlo, y construir un storefront moderno con todas las piezas —SEO, rendimiento, accesibilidad, internacionalización, checkout B2B— es un proyecto en sí mismo.

Saleor es la opción correcta cuando:

• Tu negocio es B2B con pricing por cliente, cuotes, aprobaciones o cuentas de organización.
• Integraciones con ERP, CRM o PIM son críticas para el éxito del proyecto.
• Necesitas un storefront diferenciado, multicanalidad real o operativa multimercado.
• Valoras open source, control sobre el roadmap técnico y minimizar vendor lock-in.
• Tienes (o tu partner tiene) capacidad de gobernar arquitectura composable.

Saleor NO es la opción correcta cuando:

• Tu modelo es B2C estándar con catálogo simple y time-to-market agresivo.
• No tienes equipo técnico interno ni presupuesto para un partner especializado.
• Las integraciones críticas se resuelven con apps del marketplace de Shopify.
• El coste operativo predecible de una plataforma SaaS es determinante para el negocio.
• Prefieres funcionalidad empaquetada lista de serie antes que flexibilidad arquitectónica.

Si tras leer esto sigues con dudas sobre encaje, las comparativas con otras plataformas ayudan a calibrar. Y la FAQ expandida responde a dudas más específicas.