What Broke and What Worked Across eCommerce Automation Tools

What Broke and What Worked Across eCommerce Automation Tools

ByUS Stacked

1. Zapier throttling behavior when scaling order processing automations

At one point I tried funneling new Shopify orders into a Zapier workflow that split off into inventory, email, and fulfillment paths. It worked until it didn’t—right around the 50-60 order per hour mark, things started timing out or duplicating. There was no warning, no clear resource limit hit, and Zapier’s task usage logs looked normal. The first red flag? One fulfillment webhook fired three times in a row, seconds apart, but only showed one delivery.

The issue seemed tied to Zapier’s background queue management. If your multi-path Zap takes longer than approx two seconds to execute after the trigger, throttling kicks in silently. I confirmed this running the exact same Zap with long versus short filter logic. Short branches never duplicated. Longer ones? Nightmare fuel. You’ll see unexpected parallel firing — it’s not visible in the log, but the downstream apps definitely notice.

Quick fix that held up: split workflows into narrow, single-purpose Zaps (e.g. one for tagging, one for fulfillment). More Zaps, yes — but fewer headaches. Also, drop a Delay Before Next Step of 1 minute between fast-moving steps. Dumb, but effective. Zapier’s internal rate controls don’t love speed.

2. Make dot com fails silently on missing mapped Airtable fields

This one swallowed about three hours last Thursday. A Make scenario was copying Shopify SKUs into Airtable, mapping variants into linked records. One of the fields I had mapped — “Batch Code” — had been renamed in Airtable the day before by a team member doing cleanup. The Make trigger didn’t error. No warning, no red bar. The scenario just skipped the mapping silently, every time, leaving that field blank across dozens of records.

This becomes a problem fast because Make will not error on undefined fields if the field is optional — and “optional” seems to mean “not required at Airtable’s API level,” not “field you care about.” No logs showed an error. You only notice if you click into the Airtable base and see the missing values. It’s worse if another automation downstream relies on those fields being filled in (ours launched email confirmation if batch codes existed — so yeah, those never went out).

I now prefix all Airtable-integrated fields in their names with stable aliases (e.g. “BCODE_Batch Code”) so users can edit the label without breaking the integration.

3. Shopify Flow only triggers for native event types not app-based ones

Shopify Flow is great right up until you try to use it to automate anything involving third-party event emitters. I tried to build a Flow to trigger when a Listrak marketing tag was added to a customer profile. Nothing happened. Turns out, Flow only listens to native Shopify events — and app-based actions don’t count, even if they appear in the admin timeline.

This one is not documented anywhere obvious. The telltale sign was that no Flow trigger ever fired, even on obvious timeline updates. Once I rewrote the Flow to trigger on a native tag addition (which we mimicked using a tiny Webhook-in-Zapier-to-Shopify call), it triggered just fine. The workaround was to route third-party events through a webhook layer that tags the customer with a unique Flow-specific temporary tag — then Flow picks that up and runs the rest of the automation.

It’s ugly, and you’ll eventually end up with 40+ ghost tags like flow_trigger-LT-cleanup, but at least they fire reliably.

4. N8N needs explicit error handling even for stable HTTP modules

I get why N8N made errors non-fatal by default, but it absolutely bit me last month. We were running a checkout fraud detection flow — orders go into a JSON scoring API, results get written to Airtable, alerts go to Discord. It had been quiet for a while. Then suddenly I noticed that a few risky-looking orders from Klarna had come in without triggering alerts. No errors in the run logs.

Turns out one of the requests returned a 400 due to malformed phone number data. But since the HTTP Request node doesn’t throw by default, those branches ran to completion with garbage downstream data (e.g. empty risk scores). You have to explicitly enable “Set to error if status code >= 400” on every HTTP node, or wrap it in a Try/Catch sequence manually.

This isn’t just about clean logs — if you don’t do this, the system seems to work while sending false signals. After that incident, I now template out shims for every custom API call in N8N:

  • Validate response body and status separately
  • Route bad inputs to a tagged Slack notification
  • Add path annotations for any HTTP 4xx or 5xx response
  • Use node.name tags inside the log object

That way, even when things break, they break out loud enough for Slack to yell about it.

5. PrestaShop webhooks duplicate when mixed with custom module triggers

Built a custom fulfillment flow for a merchant using PrestaShop and a few edge-case shipping partners. We wanted to fire a webhook when status moved from “Awaiting fulfillment” to “Ready to ship.” We used both PrestaShop’s native webhook + a custom module that watched order-hook events. That combo? Duplicates the webhooks about one-third of the time. Always when order updates are triggered via bulk action in the admin panel — not via API changes.

This is gross behavior. We traced it to the fact that bulk actions seem to post-process both native and module fires, but not reliably suppress one over the other. Nothing in the dev docs. Nothing in the admin UI suggests this correlation. If you’re seeing double orders downstream, this is likely why.

The fix was not to suppress one of the webhooks (too flakey) but to dedupe the inbound job using a hash of: order.id + order.status + order.modified_at. Any repeated webhook job inside a 10-second window was ignored. You could enforce that via a Redis-like caching layer or just build it into your receiver’s processing script. Doesn’t solve core duplication but it neutralized the consequences.

6. Klaviyo automated campaigns miss contacts added via API ingestion

Klaviyo behaves differently when a contact is added via frontend signup versus API ingestion. This wasn’t obvious until we started piping SKU-specific opt-ins via custom webhooks from Notion pages. API-created profiles land in the audience, but don’t get queued for campaigns triggered by list joins unless one other tracked event happens—e.g. viewed product, email open, site visit, etc.

I only caught this when a client said their “SKU-based launch list” had zero opens. The profiles existed. The campaign was live. The segment was set correctly. But nobody hit the trigger window.

This is buried in Klaviyo’s logging model. Look at the activity feed for any API-added profile. No “List Joined” event = no automation fire. The solution was dumb but worked: after each profile creation, fire a fake event (we used a custom “Interest Registered” webhook for this) and trigger off that instead. Once that runs, Klaviyo treats them like real subscribers again.

7. Quick recheck checklist for eCommerce automation reliability

Some of this stuff you won’t catch until a buyer emails asking why their package says it shipped yesterday but doesn’t exist. Or a promo fires to 0 people because half your automations assume different timezone math. I’ve built a habit list that now runs as a Monday checklist (yes, manually, until I build it better):

  • Cross-check fulfillment triggers for time-based or quantity-based lag logic
  • Re-validate webhook integrations for expected payload format (especially if multiple systems are involved)
  • Test a single product purchase from sandbox to completion — pause all price-based triggers before doing this
  • Manually review last 10 unsubscribes for weird segment logic
  • Simulate API-based contact loads and confirm downstream automations still fire
  • Hit key scenario endpoints from a mobile device with 4G network (because some automations really hate mobile-origin headers)
  • Generate a fake failed payment scenario to test Stripe or ReCharge event handling — they change tokens often

Don’t trust a green checkmark or “Scenario ran successfully” line. That just means the platform didn’t quit — doesn’t mean it did what you think it did.