Three ways to build a Shopify Webflow integration

The design lives in Webflow and the commerce engine is Shopify. The architecture question is where one hands off to the other, and every Shopify Webflow integration is an answer to it.

There are three current answers. You can embed Shopify’s Buy Button widgets in your pages, build your own front end on the Storefront API, or run a sync tool that turns Shopify products into Webflow CMS items and design the store in the Designer.

This post compares the three as architecture. For each pattern, it covers what it is, where checkout happens, what breaks first, and who it suits.

Checkout always happens on Shopify

Start with the fact that constrains all three. Shopify’s Cart reference states it in one sentence.

Use the checkoutUrl field to direct buyers to Shopify’s web checkout to complete their purchase.

Every pattern resolves through that URL. The Buy Button’s cart ends there, a custom Storefront API build ends there, and the sync tools end there too, as their vendors say themselves.

So the decision is never where checkout lives. It is who renders everything before checkout, meaning the product page, the collection grid, and the cart. The three patterns draw that seam in three different places.

Pattern A embeds the Buy Button

The Buy Button is a Shopify sales channel, included in every Shopify plan, that generates embeddable product and cart widgets. The generated code drops into a Webflow Code Embed element and renders inside your layout.

<div id="buy-button"></div>
<script src="https://sdks.shopifycdn.com/buy-button/latest/buy-button-storefront.min.js"></script>
<script>
  var client = ShopifyBuy.buildClient({
    // store domain + storefront access token
  })
  ShopifyBuy.UI.onReady(client).then(function (ui) {
    // mount the product or cart component into the div above
  })
</script>

Note whose documentation you are following. Shopify’s embed guide names WordPress, Squarespace, Wix, and its own blog, and Webflow appears nowhere in it, so a Webflow build takes the generic path of pasting script tags into custom code by hand.

Shopify also states where the widget does not belong. Its help center is direct about it.

Shopify does not recommend the use of Buy Buttons on your Shopify online store or blog, because they can cause problems with the checkout process.

That guidance draws the pattern’s territory. The Buy Button exists for external sites, which a Webflow site is, and it is not a layer over a Shopify storefront you already run.

Webflow sets the hard numbers on its side. A Code Embed element caps at 50,000 characters, and the site-wide head and footer plus each page’s head and body sections carry the same cap. That makes five separate budgets, none of which accepts server-side code.

Webflow also “cannot guarantee the functionality or full compatibility of any custom code,” and its support team will not troubleshoot it. Between the two vendors, the integration is yours to own and debug.

The failure modes live in Shopify’s own Buy Button FAQ. Buy Buttons are not compatible with Shopify apps, so a review or upsell app never reaches the widget. The FAQ’s troubleshooting section is mostly CSS problems, with entries covering site styles hiding the widget’s iframe, buttons rendering at zero height, and stale product IDs returning 404s.

The pattern suits a marketing site selling a handful of products, where the build is an afternoon and the app ecosystem does not matter. Checkout leaves for Shopify the moment the buyer commits.

Pattern B builds on the Storefront API

The Storefront API is the programmatic path, a GraphQL API that serves the store’s data to any front end you choose. Shopify’s reference is blunt about the shape.

The Storefront API is available only in GraphQL. There’s no REST API for storefronts.

What it exposes splits by authentication. Tokenless access covers products and collections, search, pages and blogs, selling plans, and cart reads and writes, under a query complexity limit of 1,000.

An access token unlocks the rest, which covers product tags, metaobjects and metafields, Online Store menus, and customer data. Tokens come as public, for browsers where buyers can see them, or private, for servers, with a cap of 100 active tokens per shop.

Rate limiting works differently than you might expect. Requests from real buyers face no fixed request-per-minute limit, and Shopify rate-limits automated traffic like bots and crawlers instead. For tokenless builds, the practical ceiling is the complexity budget, not a request count.

Checkout is the one piece you do not build. The cart assembled through the API carries a checkoutUrl, and the buyer finishes on Shopify’s hosted checkout.

query ($cartId: ID!) {
  cart(id: $cartId) {
    checkoutUrl
  }
}

Two constraints belong in the plan. First, Shopify’s terms bar using the API to duplicate existing Shopify functionality, so read them before scoping. Second, Hydrogen is optional, since the docs list “bring your own stack,” meaning “any framework, tooling, or hosting,” as a parallel first-class path.

Inside Webflow, this pattern lives in the same 50,000-character custom-code budgets as Pattern A. What changes is what fills them, because you write the storefront instead of pasting a widget.

The pattern suits teams with developers who want control of every rendered request, and a build budget to match. Everything a Shopify theme would have handed you is now yours to build and maintain.

Pattern C syncs the catalog into the Webflow CMS

The third pattern moves the product data itself. A sync tool copies Shopify products into the Webflow CMS, where each one becomes a CMS item you bind to Collection lists and style natively in the Designer. The cart, the vendors say, stays in Webflow, and checkout redirects to Shopify as always.

Webflow’s own App Marketplace lists several tools in the category, including Storesynk (formerly Shopyflow), Looop, Smootify, and blink Flow.

Their descriptions converge on one mechanism. Smootify’s listing says it connects “through the Shopify Storefront API,” and Storesynk’s FAQ calls the product “powered by Shopify’s Storefront API.” Those are vendor claims, but they add up to Pattern C being Pattern B with the build packaged as a subscription.

Storesynk publishes the fullest pricing of the group. A free Starter tier covers webflow.io domains, then Launch at $49 a month billed yearly ($59 billed monthly), Pro at $74 ($89), Multi-storefront at $147 ($177), and a services arm, Storesynk Studio, starting from $500.

Those figures were checked in September 2026, and tools in this category reprice faster than the platforms under them, so confirm on Storesynk’s pricing page before you budget.

The comparators publish less. Looop and Smootify each advertise a free plan on their marketplace listings, and blink Flow’s marketplace card shows no pricing at all.

Storesynk also states its floor, which is at least a Shopify Basic plan and a Webflow Basic plan, with Webflow Ecommerce not needed. Treat that, like every capability claim in this section, as a vendor describing itself.

One line of Webflow documentation governs the whole pattern.

Don’t enable Webflow Ecommerce if you’re using a third-party ecommerce integration. Instead, upgrade to a non-Ecommerce Site plan (i.e., CMS, Business, or Enterprise).

That is Webflow’s help center talking, not a tool’s marketing, and the same article names Shopyflow, Storesynk’s former name, as its own example of such an integration. A Pattern C site runs with Webflow’s native cart switched off.

Where the pattern breaks is catalog scale, and the plainest warning comes from Storesynk’s own FAQ.

If you have thousands of products, Storesynk might not be the right solution for you.

The reason is structural. The same FAQ explains that the sync creates a CMS item for every unique product variant, “which means you will hit Webflow’s CMS limits quite fast.” Item counts multiply past product counts quickly.

Webflow’s display layer adds its own arithmetic, since a Collection list renders at most 100 items unless pagination is enabled.

The pattern suits design-led stores whose team lives in the Designer, with a catalog in the hundreds rather than thousands. There is no storefront code to maintain, a subscription takes its place, and the vendor claims need testing against your own catalog before you commit.

Choosing the seam

Before picking a pattern, confirm that you need one. If the catalog is small and the marketing site already runs on Webflow, Webflow’s own Ecommerce may be enough, and Webflow Ecommerce vs. Shopify draws that line at roughly twenty products.

If the store already runs on Webflow Ecommerce and is hitting its limits, the question is a migration to Shopify rather than an integration, and Outgrowing Webflow Ecommerce covers the signs.

Once Shopify is the engine, the choice between the three patterns comes down to two things: how big the catalog is, and who will build and maintain the storefront.

Choose the Buy Button (Pattern A) when products are a small addition to a marketing site. A handful of products, a single developer or a capable designer, and a build measured in hours. Accept that no Shopify apps will work inside the widget, and that the site’s CSS can interfere with it, so plan a styling check on every template change.

Choose the Storefront API (Pattern B) when you have developers and want full control. Every product page, collection grid, and cart is code you write and own, which means you control every request and every render. The trade is build time and ongoing maintenance, because nothing a Shopify theme would have given you comes for free. Budget for both.

Choose a sync tool (Pattern C) when the design team lives in the Webflow Designer. Product pages become CMS items styled like every other page, with no storefront code to maintain and a monthly subscription in its place. This works while the catalog stays in the hundreds. Past that, the tools’ own vendors say the CMS fills up, so confirm your variant count against the tool’s published limits before committing.

If you are between two patterns, the catalog usually decides. A catalog too large for a sync tool and a team without developers is a Shopify storefront question, not a Webflow integration question.

How we build it

We build on both sides of this seam. Webflow front ends carry a brand, and Shopify storefronts carry a catalog.

When a project needs both platforms, our web design service scopes the seam first, because template structure, CMS design, and every line of custom code hang off that one decision.

Get in touch if you are weighing these patterns for a Houston store. Catalog size and where your team designs usually rule out two of the three before any feature comparison starts.

Frequently asked questions

Where does checkout happen when Shopify runs inside a Webflow site?

On Shopify, in every pattern. Shopify’s Cart documentation directs buyers to its hosted web checkout through the cart’s checkoutUrl field, and all three patterns resolve through it. The integration decides everything that happens before that redirect.

Can I run Webflow Ecommerce and a Shopify integration on the same site?

No. Webflow’s help center says not to enable Webflow Ecommerce when using a third-party ecommerce integration, and to run a non-Ecommerce Site plan such as CMS, Business, or Enterprise instead. The same article names a Shopify sync tool as its example of such an integration.

Do Shopify-to-Webflow sync tools handle large catalogs?

Their own vendors say no past a point. Storesynk’s FAQ warns that thousands of products will hit Webflow’s CMS limits quickly, because the sync creates a CMS item for every unique product variant. Test catalog scale first against any tool in this category.

Do I need Hydrogen to build a custom Shopify storefront?

No. Shopify documents two parallel headless paths. The first is Hydrogen, its official framework. The second is bring your own stack, described as any framework, tooling, or hosting. A Webflow front end calling the Storefront API is the second path, not a workaround.