A client emailed me in July asking whether I could rebuild their promo rules "in Webflow Logic, like the tutorial shows." The tutorial was three years old. Logic had been switched off for more than a year by the time they sent it.
That is the awkward state of Webflow Logic and ecommerce work right now: one side of the comparison no longer exists, and a lot of the writing about it has not caught up. So the useful question is not Logic versus custom code. It is which of the surviving paths each workflow belongs on, and how much of your store's behaviour you are willing to hand to something you cannot debug.
Is Webflow Logic Still Available for Ecommerce?
No. Webflow sunset Logic on 27 June 2025, disabling every existing flow and reverting Logic-connected forms back to standard Webflow forms.
The wind-down ran in two stages. New Logic flows could not be activated from 31 January 2025, and the runtime itself stopped six months later, per Webflow's deprecation notice for Logic and User Accounts. Forms kept submitting. The automations hanging off them did not, and the failure mode was quiet: submissions landed in the form inbox, and the conditional branch that used to tag the customer or fire the follow-up simply never ran.
Webflow's framing was that it would rather invest in the design and CMS layers than compete with mature automation platforms, as this breakdown of the shutdown puts it. Read that as a boundary statement. Webflow builds the storefront. Someone else runs your business rules.
If you inherited a site built during the Logic era, go check. Not the Designer, the actual behaviour: place a test order, submit the newsletter form, and confirm the downstream thing you assume still happens actually happens. On two of the three Logic-era sites I have audited, it did not, and nobody had noticed for months.
What Replaced Logic in a Webflow Ecommerce Stack?
Four paths absorbed the workload, and they are not interchangeable: external automation, vetted Webflow Apps, your own code on Webflow Cloud, or moving the commerce engine off Webflow entirely.
Pick per workflow, not per site. Most stores I look at end up running two of these at once, which is fine as long as you can say out loud which system owns which rule.
| Path | Fits | Breaks down when | What it really costs |
|---|---|---|---|
| Zapier / Make | Notifications, CRM sync, spreadsheet logging, simple branch-on-field rules | Volume spikes, retries, anything needing a database read mid-flow | Per-task pricing that scales with orders, and a black box during incidents |
| Vetted Webflow Apps | Abandoned cart, reviews, currency display, subscriptions | The app's opinion differs from yours by one field | Monthly per-app fee, plus a vendor between you and your order data |
| Your code on Webflow Cloud | Inventory reconciliation, fraud scoring, tax edge cases, anything stateful | Nobody on the team can maintain it | Engineering time, and a build you own outright |
| Commerce engine elsewhere | Multi-currency, real carrier rates, thousands of SKUs, warehouse workflows | Your brand experience is the reason people buy | A migration, and a second platform bill |
The third row is the one that changed most recently. Webflow Cloud now runs full-stack apps beside your site — Next.js 15 or later, Astro 6 and 7, or Vite 6.1 and later, all on an Edge runtime hosted on Cloudflare. That is the sanctioned place to put the logic Logic used to hold, and it removes the old argument that custom workflows meant standing up separate infrastructure.
It comes with sharp edges the docs state plainly. Only npm is supported. Your custom build script is ignored, because the platform runs the framework's own build command. Cache headers set by your app get overridden, so the invalidation tricks you rely on elsewhere do not apply. And fetch is the safe way to call external APIs, since third-party HTTP clients like axios may not survive the edge runtime. None of that is a dealbreaker. All of it is the kind of thing you would rather learn before the migration than during it.
Where Custom Code Stops Being Optional
Some ecommerce workflows have no no-code path at all on Webflow, and pretending otherwise is how projects go sideways in week five.
Multi-currency is the clearest one. Webflow checkout processes in a single currency, and the request to change that is not new. The Webflow Wishlist idea asking for multiple currencies was filed on 9 April 2019, has collected 371 votes, and still sits at Open — seven years of it being reviewed rather than shipped. One developer in that thread describes cobbling the feature together across Webflow, Airtable and Stripe. That is not an integration. That is a second store you now maintain.
Tax follows currency. Region-based rate configuration covers a domestic store selling physical goods. It does not cover digital goods sold into the EU, where the rate follows the customer's location, nor US destination-based sourcing at any real number of jurisdictions. The moment you need a tax engine's answer rather than a table you typed in, you need somewhere to call it from.
Inventory is where it bites hardest. Webflow can be a source of truth for stock, or it can mirror one. It cannot do both, and stores drift into doing both by accident. A POS at the shop, a marketplace listing, and a Webflow store all decrementing the same physical shelf will oversell within a week. Reconciliation needs a job that runs on a schedule, holds state, and can reason about which system won. Zapier is the wrong shape for that.
Fraud signals sit in the same bucket. You want to look at the order before it is fulfilled, compare it to history, and act. Off-the-shelf tools can score it, but the acting part still lives in your code.
You Cannot Run Logic Inside Webflow Checkout
Worth stating flatly, because it derails scoping calls. You can style the checkout freely. You cannot put a rule in it. Custom checkout fields are capped at three and they are plain text inputs, so there are no dropdowns and no conditional reveals. Every rule you wanted enforced at checkout has to move earlier, into the cart, or later, into a webhook.
The Webhook-and-Worker Pattern I Use
For anything that has to be reliable, I stop trying to express the rule in a builder and run it as a small service triggered by the order itself. The steps are boring on purpose.
- Register a webhook on the
ecomm_new_ordertrigger with theecommerce:readscope. This is your only real-time signal that money moved. - Have the handler do one thing: write the raw payload to a queue or table and return 200 fast. Webhook endpoints that do work inline are the ones that time out and get retried into duplicates.
- Key everything on the order ID. Retries are normal, so every downstream action needs to be safe to run twice.
- Read the money fields carefully. The Data API returns prices as an object with
unit,valueandstring— an ISO 4217 currency code alongside a value in minor units, so21155means $211.55. Treatingvalueas dollars is the classic first bug. - Reconcile on a schedule as well as on the webhook. The orders endpoint pages at a maximum of 100 records per call, so a nightly sweep needs pagination and a cursor you persist.
- Alert on your own failures. A silent workflow is exactly what everyone had after June 2025, and the whole point of owning the code is that you find out.
You have a Zap that fires on new order. What happens to it at 2am during your best sales day, when the task queue backs up and nobody is watching the dashboard? That question is the real dividing line between the no-code path and the code path, and it has nothing to do with how complex the rule is.
The Version Where You Leave the Platform
Sometimes the workflow is the product, and the storefront is the smaller half of the job.
Pizzeria Bestek is the version of that I ship most often. A family-run pizzeria on the Croatian coast, replacing a third-party ordering platform with a React and Supabase build they own outright. The ordering rules are the entire value. Delivery-zone validation runs inline at the address field before submission, rather than producing a decline email twenty minutes after the customer already assumed the food was coming. The pickup-time picker is constrained to what the kitchen can actually cook in a rolling window, so nobody books a pizza for five minutes from now. And the email templates branch across four languages on whether the order was pickup or delivery, because the alternative you suggest to a declined customer differs in each case.
None of that fits in a builder. It has run since September 2025 at five to ten orders a day, seven days a week, and the commercial argument was never about features: every order is 100% revenue instead of roughly 70% after aggregator commission. The workflow logic was the reason to write code, and the site came along with it.
When to Stop Fighting the Platform
Actually, let me push back on my own framing for a second. Most Webflow stores should not be writing any of this. If you sell forty products in one currency to one country, the native tools plus one app cover you, and every hour spent on webhook infrastructure is an hour not spent on the product photography that actually sells.
The signal to move is not complexity in the abstract. It is a rule you have already written down twice in two systems. When your promo logic exists both in a Webflow discount code and in a Zap that emails a different discount to a different segment, you have two sources of truth and you will ship a contradiction. That is the week to consolidate.
If the automation is genuinely light, keep it light: pairing Webflow with Zapier handles more than people expect, and it runs entirely off-page so it costs you nothing in load time. If the constraint turns out to be the CMS layer rather than the workflows, my rundown of the best CMS platforms for marketing sites covers where Webflow genuinely wins and where it does not. And if you are weighing a self-hosted editor against a bespoke front end instead, WordPress versus a custom website build is the fork that matters more than any plugin comparison. Before you commit to any of it, what a website build actually costs will tell you whether the custom path is even in budget this year.
Go open your Webflow site's Integrations panel and list every automation currently touching an order. Then, next to each one, write the name of the person who would fix it at 2am. If any row is blank, that workflow does not belong where it is.
