PIM Integration e.g. Akeneo

Extensibility and Integrations
1

Are there any best practices, code snippets (e.g. for mixins) etc. available for PIM Integrations e.g. with Akeneo?

It is clear that this is possible with the API-first approach, but there may be different approaches, particularly regarding variants and classification categories—including in light of recently introduced and upcoming new features (which could change previous recommendations).

The question is which methods are practical and what the respective pros and cons are (e.g., one method makes the import easy but is slow, while the other is fast during import but slows down the product API for the storefront). And what about flexibility when making changes to data structures in the PIM? Here, too, there could be differences in the approaches.

Are there any experiences, best practices and examples that can be shared here or in the documentation?

2

Hi Georg, good to see you here! This is actually a topic I’m happy to dig into a bit more publicly, since it comes up a lot. So thanks for the question.

You are right, there are new features specifically designed for this use case. Our dynamic variants are recently released at API level — full support in the Management Dashboard, storefront, and more documentation will follow in the next weeks.

You can find the release notes here: https://developer.emporix.io/changelog/2026/2026-04-27-product

Variants

There are two approaches, and the right one depends on whether you want Emporix to own validation or whether you’re happy to leave that to the PIM.

The classic, template-based approach: you define variantAttributes on the parent product first, and every child must match that template. Emporix validates against it. That’s great for data integrity, but the moment your PIM adds a new variant attribute you have to update the parent template first — and only then can you push the updated children. For a PIM-driven sync that’s a real pain.

The new dynamic variants approach drops that constraint entirely. You skip the parent template and define variantAttributes directly on the child variants — they’re generated dynamically. Adding a new variant attribute in Akeneo? Just include it in the next sync. Nothing to update on the parent first.

The trade-off: Emporix no longer validates that your children are consistent with each other. In my opinion that’s perfectly fine when you have a leading PIM — that validation is already happening there, no need to duplicate it.

There are more benefits to the new dynamic variants. Check the release notes. I would definitely recommend using this approach going forward.

Classification

Here I’d also distinguish two approaches.

The built-in classification categories are purpose-built for this, and they make sense if you want to manage or enrich the classification structure inside Emporix — e.g., if business users need to browse or adjust it in the Management Dashboard. The downside is that you now have a second hierarchy to sync: the structure from the PIM has to land in Emporix first, before you can assign products to it. That’s a meaningful extra layer of complexity, especially if these classifications change a lot and in my experience it’s only worth it if Emporix really is co-owning that classification. But here I am happy to hear if there might be other use-cases for wanting to have the classification in Emporix.

If the PIM is the single source of truth for classification and you’re just pushing products into Emporix, the simpler path is to use mixins with a naming convention that mirrors your attribute groups. One mixin schema per attribute group (e.g., akeneoClassPath_electrical_specs, akeneoClassPath_packaging_attributes), and when you import a product you include only the mixins relevant to its family, with their values. The assignment lives entirely in the PIM — Emporix stores and validates the field values, but doesn’t need to know about the classification hierarchy at all.

json

{
  "code": "PRD-001",
  "name": { "en": "Industrial Switch" },
  "metadata": {
    "mixins": {
      "electricIndustry_electrical_specs": "https://res.cloudinary.com/...schema-electrical.json",
      "electric_packaging_attributes": "https://res.cloudinary.com/...schema-packaging.json"
    }
  },
  "mixins": {
    "electricIndustry_electrical_specs": { "voltage": 240, "current": "16A" },
    "electric_packaging_attributes": { "weightKg": 0.45, "packagingType": "BOX" }
  }
}

One thing I’d flag upfront: the mixin key (e.g., electric-industry_electrical_specs) gets stored on every product record. Renaming it later means touching every product that uses it — so treat these as stable identifiers from day one and align them with something that’s stable in the PIM too. In case of classification / schema changes: the mixins are versioned so when your classification attributes changes you can use the latest version on update. You can then update the mixins field for every product in the classification-category or depending on the kind of change only update the products when you touch their product data anyway. In case of a new field, you could only update the products that actually have data in this field.

Happy to discuss further here or jump on a call if it’s easier — especially the classification use cases --just ping me!

Andi

3

Hi Andi,

thanks for your reply. I think the approach with dynamic variants is the most promising and flexible in this case.

My current idea would be to map the Akeneo product models to not sellable dynamic variants and the products to a sellable dynamic variant product.

I’m also thinking about how to sync this in a efficient way (delta import) with taking into account that not all Akeneo products are relevant for the import and also avoid multiple calls to same things like reference entities, attribute-groups, attribute values.

Georg