Comparison

Cin7 native commerce vs decoupled commerce vs middleware: how to choose

Cin7 customers shipping commerce on top of Cin7 land on one of three architecture patterns: native connector, decoupled architecture, or middleware-mediated. None is universally best. The right one is decided by your channel mix, the depth of business logic that lives only in Cin7, and the integration capacity your team is willing to own. This guide walks the three patterns honestly, names where each one earns its keep, and gives you the decision framework to choose without vendor pressure.

What "native" actually means in the Cin7 context

Native, in the Cin7 ecosystem, usually means a Cin7-built or Cin7-certified connector that syncs the core entities most sellers need first: products, prices, customers, orders, and inventory. The connectors cover Shopify, BigCommerce, Magento, Squarespace, WooCommerce on the storefront side, and Amazon, Walmart, eBay, Faire, and Joor on the marketplace side. They sync on a schedule (or via webhooks where supported) and they aim to be the lowest-friction path to a working channel.

Native connectors carry the entities they were built to carry, at the cadence they were built to sync, with the field coverage the connector vendor decided to support. That is a feature, not a defect. Native is supposed to be cheap, fast, and predictable. The trade-off is that when your business logic does not fit cleanly inside the connector’s data model (multi-tier customer pricing with effective dates, configurator-to-quote workflows, multi-warehouse available-to-promise that calls Cin7 in real time), native starts requiring workarounds. The right reaction is not to fight the connector; the right reaction is to ask whether your scope has outgrown native rather than whether the connector is wrong.

Native is the right answer when you run one or two channels, your business logic fits the connector’s field coverage, and you want the cheapest fast path to a working storefront. Most early-stage Cin7 customers start here and ship well.

What "decoupled" actually means in the Cin7 context

Decoupled, in this context, means the storefront talks to Cin7’s REST API at request time rather than relying on a periodic sync. Available-to-promise reads a live Cin7 inventory call when the buyer opens the cart. Customer-specific pricing for the wholesale channel calculates against live Cin7 customer terms. Order capture posts directly to Cin7 with the same fields Cin7 would write internally. The storefront becomes a thin renderer; Cin7 carries the truth.

Decoupled is the right answer when the buyer experience needs to honour business logic that lives only in Cin7 and that the storefront platform’s data model cannot represent cleanly. Wholesale buyers with multi-tier contract pricing, manufacturers with configurator-driven SKUs, sellers with multi-warehouse promised dates that have to be live, multi-currency storefronts that read live Cin7 truth across regions. Decoupled scales cleanly to additional channels because the integration layer is purpose-built rather than a stitched series of connectors.

The trade-off is heavier integration ownership. Someone has to design the contract between Cin7 and the storefront, build the integration layer (often as a small service that fronts the Cin7 API), and own its uptime and evolution. For brands that already run an engineering function or have a partner like Acro Commerce, that ownership is reasonable. For brands that do not, decoupled is the wrong call regardless of how well it fits the buyer experience.

What "middleware" actually means in the Cin7 context

Middleware sits between native and decoupled. It is an integration layer (sometimes a connector ISV’s product, sometimes a custom-built service) that consolidates Cin7 API calls, applies business rules the storefront cannot, and exposes a stable contract to the commerce layer. Middleware is most common in brands running three or more channels (DTC storefront, wholesale platform, marketplace, plus EDI to retail) where a shared business-rule layer between Cin7 and each channel is cheaper to maintain than repeated logic inside each channel.

Middleware is the right answer when the storefront platform is fixed but the business logic is more complex than the platform’s native data model can carry, or when several channels need a common business-rule layer. It is also the right answer when you want to keep the storefront platform replaceable without rebuilding the Cin7 contract; the middleware layer is the contract, and the storefront platform becomes a downstream renderer.

The trade-off is a third system in the stack. Middleware introduces operational complexity that is justified when it consolidates duplicated logic across channels and unjustified when teams reach for it to avoid scoping the integration cleanly. The most common middleware failure mode is the middleware that grows into a parallel ERP because the team kept adding logic to it instead of pushing logic back into Cin7. Treat middleware as a contract layer, not as a place to put business logic that belongs upstream.

Side by side: who each pattern actually fits

Native fits brands with one or two channels, business logic that fits the connector’s data model, and a preference for off-the-shelf operational ownership. Time to first release is fastest, ongoing maintenance is lowest, integration depth is shallowest. The brand grows comfortably until its logic outruns the connector, at which point the next move is decoupled or middleware, not a deeper customisation of the connector.

Decoupled fits brands where the buyer experience depends on live Cin7 truth, where business logic lives only in Cin7, and where the team or its partner can own the integration layer. Time to first release is moderate (longer than native, shorter than enterprise replatforms). Ongoing maintenance scales linearly with the integration layer’s surface area, which is bounded by the contract between Cin7 and the storefront. Channel additions are clean because each new channel calls the same integration layer.

Middleware fits brands running three or more channels with shared business logic that should live once rather than per-channel, or brands that want a stable contract layer between Cin7 and a replaceable storefront. Time to first release is longest because the middleware contract has to be designed before the first channel ships. Ongoing maintenance is higher than decoupled if the middleware accretes logic that should live in Cin7; lower than decoupled-per-channel if the middleware keeps to its role as a contract layer.

None of these patterns is a permanent choice. Brands often start native, move to decoupled when buyer experience demands live truth, and adopt middleware when the channel count crosses a threshold where shared logic is cheaper than per-channel duplication. The architecture should match the business at each stage rather than anticipate stages that may not arrive.

How to decide: the three-variable framework

Acro Commerce uses three variables to drive the architecture choice on Cin7. Score each as low, medium, or high for your brand, then map the combined score to the pattern. The framework is not deterministic; it forces the conversation onto variables that matter rather than onto storefront preference.

Variable 1: channel breadth. How many channels read inventory truth from Cin7? One channel scores low. Two to three channels with similar buyer experiences score medium. Four or more channels, or channels with very different buyer experiences (DTC + wholesale + marketplace + EDI), score high. Channel breadth pushes the decision toward middleware as it climbs.

Variable 2: business-logic depth in Cin7. How much of the commercial truth your storefront needs lives only in Cin7? Standard catalogue and inventory scores low. Customer-specific pricing or multi-warehouse promised dates score medium. Multi-tier contract pricing with effective dates, configurator-to-quote workflows, or live multi-warehouse available-to-promise scores high. Business-logic depth pushes the decision toward decoupled as it climbs.

Variable 3: integration ownership capacity. Will your team or your partner own an integration layer? No, the connector should carry it scores low. Yes, but only the parts that the connector cannot reach scores medium. Yes, we are willing to own a purpose-built integration layer or contract layer scores high. Integration ownership capacity is the constraint that disqualifies decoupled and middleware when it scores low, regardless of the other two variables.

Map the combined score to the pattern: low or medium across all three, native. Medium-or-high on business-logic depth with medium-or-high on ownership capacity, decoupled. High on channel breadth with medium-or-high on ownership capacity, middleware. Honest scoring usually points to a single pattern; cases where the scoring is genuinely tied are typically brands that should run native first and graduate later, not brands that should pick the more complex pattern by default.

Where this comparison sits in the broader pillar

This guide answers the architecture-pattern choice. The Cin7 commerce ecosystem hub covers the broader landscape and the readiness report covers whether your brand is ready to ship at all. Once the architecture is chosen, the partner qualification framework covers who should be in the room for the build.

Beyond this pillar: Pillar 1 (ERP-centric B2B commerce) is the foundational thesis that ERPs and source-of-truth platforms carry operational truth. Pillar 2 (architecture and platform fit) compares architecture patterns across platforms more broadly. Pillar 6 (decoupled and composable commerce) goes deeper on the decoupled pattern referenced here.

Frequently Asked Questions

Next Step

Get the foundation right before you build.

For readers scoping a platform decision or wanting a full architecture recommendation.