Comparisons
Zapier alternative: an integration for the flows that carry orders and stock
Zapier connects more than 9,000 apps with one-way automations that a non-developer can build in an afternoon. Its own documentation sets the limits that matter for an ERP: polling intervals, runs held at 100 items, five replays over 10 hours and 35 minutes. A custom integration is built around your order and stock volumes and the APIs of your store and ERP.
What Zapier does well
Zapier connects more than 9,000 apps. A Zap is a trigger in one app followed by actions in others, with filters, paths, delays and loops in between, up to 100 steps per Zap and 1,000 fields per action step. Where an app has no ready action, Webhooks by Zapier sends or catches an HTTP request, and Code by Zapier runs JavaScript on Node.js 22 or Python 3.13: 30 seconds per step on Professional and Team, 2 minutes on Enterprise, and up to 10 minutes with extended runtimes.
The commerce apps are broader than they were. The Shopify app has instant triggers for New Order, Updated Order, New Refund, New Cancelled Order and New Company, and actions for draft orders, customers and B2B company locations. The NetSuite app installs through the Zapier Automation SuiteApp and offers Upsert Record, Transform Record, Run SuiteQL Query and Bulk Import Records through a saved CSV import. Failed steps can be replayed by hand or automatically, and Zap history keeps every run for 29 to 69 days.
For low-volume flows between many apps, this is fast to set up and needs no developer: a Slack message for an order above a set amount, a new wholesale customer added to the CRM, a refund logged in a sheet. Statements about Zapier on this page come from help.zapier.com and zapier.com, read on October 3, 2026.
How a Zap moves store and ERP data
Every Zap starts from a trigger, and the trigger type is fixed by the app. An instant trigger receives a webhook; a polling trigger asks the app for new data on an interval set by the Zapier plan. For a Shopify and NetSuite setup, the documented triggers split like this:
| App on Zapier | Trigger type | Documented triggers |
|---|---|---|
| Shopify | Instant | New Order, Updated Order, New Cancelled Order, New Refund, New Customer, New Company |
| Shopify | Polling | New Abandoned Cart, New Fraudulent Order |
| NetSuite | Polling | New Record, New Or Updated Record, New Record (Saved Search) |
The Shopify list has no product or inventory trigger, and every NetSuite trigger polls. A polling trigger runs every 15 minutes on Free, every 2 minutes on Professional and every minute on Team and Enterprise. Orders can travel from Shopify to NetSuite on a webhook; stock, prices and fulfillments travel from NetSuite to Shopify on a poll.
Zapier also states that it does not support two-way syncing. A Zap is one-way; two Zaps in opposite directions can imitate a sync, and Zapier warns that a Zap that writes back to the resource it watches can trigger itself again. Which system owns which field is something you decide outside Zapier and enforce with filters. Our comparison of custom integration and iPaaS covers task counting and the general pattern; this page covers what Zapier documents about volume and failures.
Where Zapier's documentation draws limits
Zapier is a shared service, and its Zap limits page describes how it protects itself and your task allowance. These are the limits that matter for an order or stock flow:
| Area | What Zapier documents |
|---|---|
| Bulk changes | 100 or more items from a polling trigger at once are held until you confirm by email; replayed runs go at 1 per second |
| Records per poll | Set by the app, for example only the 100 most recent events or the last 24 hours |
| Instant triggers | A 429 above 20,000 requests per 5 minutes per user. Under high load Webhooks by Zapier may answer 200 and process several minutes later |
| App rate limits | One app's API limit is shared across all Zaps in the account |
| Task limit | When the monthly allowance runs out, all actions in the account are held until the cycle resets or you upgrade |
| Replay | Autoreplay retries a failed step up to 5 times; Filter and Paths steps are never replayed; replay must happen within 60 days |
| Errors | A Zap that errors on 95% of its runs, with more than 20 runs in the past 7 days, is turned off; Team accounts get 24 hours of grace, Enterprise 72 |
| NetSuite saved search | The trigger deduplicates on Internal ID; a search with several rows per record can fail with a duplicate primary key error |
None of these is a defect. They are the rules of a platform that runs many customers' automations on shared infrastructure. For a flow that carries orders or stock, each one is a moment where a person has to step in, and the replay rules decide how long a failed order waits before anyone hears about it.
Two examples from a Shopify and NetSuite store
An order that fails at 4:00 PM. A Zap takes Shopify New Order, finds or creates the customer in NetSuite and creates the sales order. At 4:00 PM the NetSuite step fails, for instance because a warehouse integration is using the account's concurrency slots and NetSuite answers 429 with CONCURRENCY_LIMIT_EXCEEDED. With autoreplay on, Zapier tries again 5 minutes later, then after 30 minutes, 1 hour, 3 hours and 6 hours.
5 + 30 + 60 + 180 + 360 minutes is 635 minutes, 10 hours and 35 minutes. If the cause was a short concurrency peak, the 4:05 PM attempt will usually go through. If the cause is data, such as a ship-to state NetSuite rejects, all five attempts fail and the first error email arrives at 2:35 AM. Until then the order is in Shopify and not in NetSuite, and the warehouse that picks from NetSuite does not see it.
A price update of 1,800 items. At 11:00 PM a CSV import changes the base price of 1,800 items in NetSuite. A Zap on New Or Updated Record polls every 2 minutes on Professional. If the app returns all 1,800 changed items in one poll, flood protection holds them and sends a confirmation email. Someone confirms at 7:30 AM, and at 1 run per second the 1,800 runs take 1,800 seconds, 30 minutes. Shopify shows the old prices until about 8:00 AM, nine hours after the import.
A custom integration reads the changed items with a SuiteQL query on lastmodifieddate. SuiteQL returns 1,000 rows per page: 1,800 / 1,000 = 1.8, so 2 pages. The 1,800 prices go to Shopify as one JSONL file, uploaded once and applied by a single bulk mutation operation that Shopify runs in the background. That is a handful of API calls a few minutes after the import, with no confirmation step. How to work out these sums for your own catalog is in integration throughput.
What a custom integration does differently
We build the integration to your systems and your rules, then host and run it. Point by point against the table above:
| Area | Custom integration, hosted and run |
|---|---|
| Bulk changes | Read through bulk queries and changed-since filters, written in batches; no hold and no confirmation per batch |
| Records per poll | Changed records since the last run, paged to the end, so no change falls outside a window |
| Order intake | Shopify webhooks land in a queue; a nightly comparison catches any webhook that never arrived |
| Failures | Retries with growing pauses for temporary errors; a data error goes to the dashboard at once with the reason, not after 10 hours |
| Ordering | Updates to the same order are processed one at a time, in the order they arrived |
| Direction | Ownership set per field, so a write never comes back as a new trigger |
The API limits stay the same. NetSuite's concurrency limit applies to a Zap and to a custom integration alike, as described in NetSuite concurrency limits. The difference is how many calls a flow spends and what it does with a refusal. Webhooks arrive at least once and sometimes out of order, which is why the queue checks each event against the record before writing, as explained in webhooks are not a guarantee.
Before go-live the integration runs as a dry run with approval. After that, the dashboard shows per run which record changed from which value to which. We monitor it and change it when Shopify releases a new API version or NetSuite changes a record. The order flow as a whole is on ecommerce ERP integration.
Moving off Zapier
The switch goes one flow at a time, starting with the flow that costs the most when it fails: orders, then stock and prices. The custom integration first runs next to the Zap with writes disabled. It reads the same orders and shows what it would write, and the difference with what the Zap wrote is visible per record. Zap history covers 29 to 69 days, which is the window to compare against.
Zaps often hold rules that are written down nowhere else: a filter on an order tag, a path for one sales channel, a Formatter step that rewrites a state name, a Code step that splits a SKU. The parallel run makes them visible, because the outputs differ where the rule applies. Once the outputs match, the Zap is turned off in the same step as the new flow goes live, so each record type has one owner. The general method is in replacing an integration, and the Shopify and NetSuite specifics are on Shopify NetSuite integration.
Tell us which Zaps carry your orders, stock or prices, and you get a fixed price for the integration that takes them over.
Frequently asked questions
Can Zapier keep Shopify and NetSuite in sync both ways?
Not in one Zap. Zapier states that a Zap is a one-way automation and that it does not support two-way syncing. Two Zaps in opposite directions can imitate it, and Zapier warns that they can form a loop that runs on the same data and uses up tasks. A custom integration sets which system owns each field, so a write from one side never triggers a write back.
How often does Zapier check NetSuite for new records?
The NetSuite app on Zapier has three triggers and all three are polling triggers. The polling interval depends on the plan: 15 minutes on Free, 2 minutes on Professional and 1 minute on Team and Enterprise. Enterprise accounts can set it per Zap in 1-minute steps up to 15 minutes.
What happens when 500 records change at once?
With a polling trigger, Zapier holds 100 or more new items that arrive at once and sends an email asking you to confirm them. After confirmation the runs go at 1 per second, so 500 runs take 8 minutes and 20 seconds. How many records a poll returns is set by the app, so some changes may not reach the Zap at all.
Does Zapier tell me when an order fails?
Yes, after the retries. With autoreplay on, Zapier retries a failed step up to 5 times over about 10 hours and 35 minutes and sends no error email until the last attempt fails. A Zap that errors on 95% of its runs, with more than 20 runs in 7 days, is turned off. See what happens when a sync fails for how a queue handles the same error.
Do I have to replace all of my Zaps?
No. The flows that write orders, stock, prices and invoices move to the custom integration. Zaps that post a message, add a spreadsheet row or update a CRM contact can keep running, as long as no Zap and the integration write the same field.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase