Posted in Digital Commerce
June 8, 2026
Comparison
When Cin7's native connector is enough, and when you extend it
Cin7 builds and maintains its own storefront connectors, which changes the shape of this decision. On most ERPs you're choosing what to put between the storefront and the back office. On Cin7 that piece already exists and the vendor supports it, so the question becomes narrower and more useful: what does the connector not reach, and does that gap matter to how you sell?
Key takeaway
Start from the assumption that Cin7's connector does the core sync, because it does. Scope the work around what it leaves out, usually contract pricing, approvals, quote-to-order, and cross-location fulfilment. If nothing on that list applies, the native connector is the whole answer.
What does Cin7 ship, and what does it cost?
Cin7 publishes native connectors to Shopify, BigCommerce, Adobe Commerce, WooCommerce, and Amazon, for both Core and Omni. They handle the core traffic: products out, inventory levels out, orders in, order status back. Cin7 maintains them, which means the integration isn't sitting on a third party's release schedule.
Settle the licensing before the architecture. Each connected store consumes one integration add-on on a Cin7 Core subscription. Two are included on Standard, four on Pro, six on Advanced, and more can be purchased. If your plan involves several storefronts, several brands, or a separate B2B site, that count is a line item, not a footnote.
Which Cin7 connector is the strongest?
Shopify, and it isn't close. Grading all 143 connector capabilities on each Cin7 edition puts Shopify at 2.06 out of three on Cin7 Core and BigCommerce at 1.81, the widest gap among the four storefront connectors, with Adobe Commerce and WooCommerce between them. Cin7's own partnership team says the same thing from the field. When the data and the practitioners agree, that's usually the answer.
That doesn't make BigCommerce a wrong answer. It means a BigCommerce build on Cin7 carries more integration work to reach the same place, and the scope should say so out loud, before month three says it for you.
What doesn't the native connector reach?
Four gaps come up repeatedly. None of them is a defect. They're the difference between syncing records and running a buying experience.
- Contract pricing per account – Cin7 holds price tiers and customer-specific prices. Rendering the right price to a logged-in buyer, for their account, on every product page, is storefront work that has to read from Cin7 instead of caching a copy.
- Approvals and quote-to-order – Buyer-initiated quotes, an approver who has to sign off before an order commits, and saved lists for reordering. These live above the connector.
- Cross-location fulfilment orchestration – Cin7 knows stock by location. Deciding which location ships a given order, or splitting one order across two, is logic somebody has to write.
- Configured or made-to-size products – If the buyer specifies dimensions or builds a product from options, the validation has to happen before the order reaches Cin7, because Cin7 will store what it's given.
We'd rather describe the resulting work as extending the connector than bridging to Cin7. The distinction isn't pedantry. A bridge implies the vendor's integration is being worked around, which on Cin7 isn't what's happening: it keeps doing the core sync and the extension covers what it was never built to do.
What if there's no connector for your platform?
Some storefronts have no Cin7 connector. Shopware is the one we get asked about most, and there isn't a native Cin7 integration for it, so that pairing is a custom build and should be priced as one. The same applies to any headless front end reading Cin7 through its API directly.
That's a legitimate architecture when the buying experience genuinely needs it. It's the wrong architecture when it's chosen for preference, because you've taken on the maintenance of something Cin7 would otherwise maintain for you.
When is a custom build the wrong answer?
Our own accelerator, Gesso, isn't the answer to every Cin7 project and we don't propose it as one. It earns its place when mandatory integrations go beyond the standard set of commerce, inventory and order platform, accounting, 3PL, and EDI. If those five cover the business, the shortest path is a supported storefront on Cin7's own connector, extended where it needs to be.
How do you make the call?
Write down how a customer buys from you today, in order, including the parts that happen over the phone or by email. Then mark each step as something the storefront does, something Cin7 does, or something a person does. Steps in the third column are the scope. If that column is empty, the native connector on a supported storefront is the whole project, and you should resist making it more interesting than that.
What to take from this
- The connector is the vendor's, so start there – Cin7 builds and maintains it. Scope what it misses, not what to replace it with.
- Shopify is the strongest path on Core – 2.06 against BigCommerce at 1.81 across 143 graded capabilities. A BigCommerce build gets to the same place with more integration work.
- Count the storefronts before you architect – Each connected store consumes an integration add-on, and the plan tier caps how many you get.
- No connector means custom – Shopware and headless front ends have no native Cin7 integration, which is a valid choice priced as a build, not a default.
For what Cin7 runs and where accounting sits, start at the Cin7 ecosystem hub. For keeping stock honest once several channels read from it, see one inventory truth across channels.
Related Articles
Cin7 commerce: how to architect commerce on Cin7
- The Cin7 commerce readiness report 2026
- Cin7 native commerce vs decoupled commerce vs middleware
- How Cin7 implementation partners qualify a commerce opportunity
- Multi-channel inventory truth in Cin7 commerce
- Cin7 customer spotlight: a multi-channel brand on Cin7 Core
- Cin7 customer spotlight: a wholesale manufacturer on Cin7 Omni
Frequently Asked Questions
Should I use Cin7’s native commerce, a decoupled architecture, or middleware?
Score three variables: channel breadth (how many channels read Cin7 inventory truth), business-logic depth in Cin7 (how much commercial truth lives only in Cin7), and integration ownership capacity (whether your team or partner will own an integration layer). Low or medium across all three points to native. Medium-or-high on business-logic depth with capacity to own the integration points to decoupled. High on channel breadth with ownership capacity points to middleware. Honest scoring usually points to a single pattern.
Is native Cin7 commerce ever good enough for B2B?
Yes, for single-channel B2B builds with standard contract terms and customer-specific pricing that fits the connector’s field coverage. Most early-stage Cin7 wholesale customers ship well on native. The pattern that breaks native is multi-tier pricing with effective dates, multi-warehouse available-to-promise, or configurator-driven SKUs; brands that hit those should plan to graduate to decoupled or middleware rather than fight the connector.
When is decoupled the wrong call on Cin7?
When your team has no integration ownership capacity and no partner to provide it. Decoupled architectures require someone to design the contract between Cin7 and the storefront, build the integration layer, and own its uptime. Brands that adopt decoupled without that ownership end up with brittle integrations that no one maintains, which is worse than running native with the connector’s limitations.
When does middleware make sense on Cin7?
When you run three or more channels with shared business logic that should live once rather than per-channel, or when you want a stable contract layer between Cin7 and a replaceable storefront. Middleware consolidates duplicated logic across channels and lets the storefront platform become a downstream renderer. It is the wrong call when the team reaches for it to avoid scoping the integration cleanly; treat middleware as a contract layer, not a place to dump business logic.
Can I start native and move to decoupled later?
Yes, and that is the most common path. Brands typically start native to ship a first channel quickly, graduate to decoupled when buyer experience demands live Cin7 truth, and adopt middleware when channel count crosses the threshold where shared logic is cheaper than per-channel duplication. The architecture should match the business at each stage. Anticipating stages that may not arrive is a common over-architecture mistake.
How does decoupled Cin7 commerce compare to decoupled Shopify or BigCommerce?
The pattern is the same: the storefront becomes a thin renderer that calls the back-end API at request time. The difference is which platform carries the truth. Decoupled Cin7 commerce keeps the operational truth (inventory, customer terms, order capture) in Cin7, with the storefront serving the buyer experience. Decoupled Shopify or BigCommerce typically refers to a thin storefront calling the platform’s own commerce API; that pattern still needs an integration to Cin7 for inventory and order truth.
Does middleware mean I need a third vendor?
Not necessarily. Middleware can be an ISV product (some connector vendors offer middleware-style products) or a custom-built service maintained by your engineering team or a commerce architecture partner. The decision is who owns the middleware’s evolution, not whether a third vendor is in the picture. Custom middleware is often cheaper long-term for brands with channel breadth that demands it.
What is the cheapest mistake brands make in this architecture choice?
Picking by storefront preference rather than by channel mix and business logic. Brands that pick a storefront they like and then design the integration around it consistently end up in one of two failure modes: an architecture that is wrong for the business, or an integration layer that exists to compensate for the storefront mismatch. Score the three variables first; let the architecture pattern fall out of the scoring; let the storefront platform be a downstream choice.
Where does Cin7 itself recommend customers go?
Cin7 leads with its native connectors because they are the lowest-friction path to a working channel and the fastest to ship. That is sound advice for most early-stage Cin7 customers. Cin7 implementation partners and commerce architecture partners (including Acro Commerce) are the right read on decoupled and middleware patterns because they have to own the integration layer in practice. Ask the partner who will own the integration which pattern they recommend, not the platform vendor.
How do I avoid the middleware-becomes-a-parallel-ERP failure mode?
Treat middleware as a contract layer between Cin7 and the storefront, not as a place to add business logic that belongs upstream. Every business rule the middleware enforces is a rule that should be evaluated for whether it belongs in Cin7. Brands that hold this discipline keep the middleware small and stable; brands that accrete logic into the middleware over years end up with a third system to maintain that no one fully understands.
Next Step
Get the foundation right before you build.
For readers scoping a platform decision or wanting a full architecture recommendation.