---
title: "The integration that makes design-to-order commerce actually work"
url: https://www.axelerant.com/blog/magento-3d-planner-integration
published: 2026-07-22T10:00:00Z
author: "Bassam Ismail, Director of Digital Engineering"
source: Axelerant Thinking
---

# The integration that makes design-to-order commerce actually work

> How we integrated a third-party 3D kitchen planner with Magento so a customer's design becomes a priced basket with full order traceability.

Nobody buys a kitchen from a product grid. They need to see it in their room, at their dimensions, before they will spend that kind of money. So when we built [the commerce platform for a UK kitchen manufacturer going direct to consumer](/blog/commerce-platform-manufacturer-d2c-leap), the 3D planner was not a feature. It was the primary purchase path, and everything else had to serve it.

The planner itself is a third-party product, embedded in our Next.js frontend as an iframe. We did not build the planner. We built everything that makes it commerce.

### What we ran into

Two systems each believed they owned the product catalog. Magento holds the real catalog: SKUs, pricing, stock, product types. The planner needs its own mirrored copy of those products to render them in 3D. Any drift between the two means a customer designs a kitchen containing something they cannot actually buy, at a price that is not actually the price. And the planner's product metadata was finalized two weeks before go-live, so the mirroring had to be robust against late-arriving data, not dependent on it being clean early.

The second problem was ours. Partway through implementation, we found the existing planner integration had been built on deeply hardcoded behavior. It worked for the demo paths and would not survive the remaining requirements. Patching it would have meant carrying that fragility into production.

### What we did and why

We rebuilt the integration layer rather than patching it. One frontend engineer redesigned the orchestration code around the planner's APIs and shipped the rework, estimated at a full sprint, in two days, with AI-assisted development doing the mechanical lifting while the design decisions stayed human. [We unpacked how that workflow held up under a real launch date here](/blog/ai-assisted-development-commerce-launch). The lesson is not the speed. It is that when your core integration is wrong, the cheapest time to rebuild it is always now.

The flow we landed on: the customer designs in the planner, and on exit the design converts to a bill of materials that syncs into the Magento basket. Crucially, it merges. A returning customer with samples already in their basket keeps them; the kitchen products join the same basket, mixed product types and all. The planner handles design only. Magento handles everything transactional: basket, checkout, payment, order.

Then there is traceability, the requirement that looks small and is not. The plan ID stays locked to the basket even as the customer edits it, carries through checkout, is exposed to the customer, and passes to the manufacturer on the order. Fulfillment can trace any order back to the exact design that produced it. When a customer calls about their kitchen, support is looking at the same plan they built.

We also handled the unglamorous edges: routing planner exit by authentication state so guests and account holders land in the right place, saved plans customers can return to and download, and entry and exit messaging so people understand they are moving between design and shop.

### What changed

At launch, the planner-to-basket path worked end to end on the first live order. A customer can design a kitchen from the real catalog, convert it to a priced basket in one step, and buy it. The manufacturer receives orders with design-level traceability they never had in their offline process.

### What you can take from this

If your commerce experience depends on a third-party design or configuration tool, treat the integration layer as your product, not glue code. Own the catalog mirroring contract explicitly, decide early which system is transactional truth, and make the design-to-order identifier a first-class citizen of your order model. And if you discover your integration is hardcoded around happy paths, rebuild it before launch forces you to. It is never cheaper later.

The architecture that made this integration possible, a Next.js frontend over Magento and Strapi, is worth its own read: [why we put Strapi next to Magento instead of fighting Magento's CMS](/blog/strapi-magento-composable-commerce).

If you are wiring a configurator or planner into commerce, we are happy to compare notes.

---

Read on the web: https://www.axelerant.com/blog/magento-3d-planner-integration