NetSuite is rarely the only system in the building. There is a Shopify store, a Salesforce instance, a 3PL, a payment processor, maybe an EDI network and a planning tool. The value of an ERP depends heavily on how well data moves between it and everything else, and this is exactly where mid-market companies burn the most money on the wrong architecture.
There are three fundamental ways to integrate NetSuite with another system. Each is the right answer for someone. Most integration disasters trace back to picking the wrong one, so here is how the decision actually works.
Option 1: Native and Vendor-Built Connectors
Many SaaS products ship a pre-built NetSuite connector: a SuiteApp or hosted sync that moves data between the two systems with configuration rather than code. NetSuite Connector (formerly FarApp) covers common eCommerce and marketplace scenarios. Plenty of vendors offer their own.
The appeal is obvious. Fast deployment, low upfront cost, vendor-maintained, no developers required. For a simple, standard flow, say syncing Shopify orders to NetSuite sales orders with inventory levels going back the other way, a good connector can be live in days.
The limits are just as real. Connectors implement the vendor’s idea of the integration, and your business lives in the gaps. Field mappings are constrained to what the connector exposes. Custom fields, unusual order flows, kit and bundle logic, or multi-subsidiary routing frequently fall outside what the connector can express. Error handling is often a black box: when a sync fails at 2 a.m., you find out from a missing order, not an alert. And you are dependent on the vendor’s roadmap for fixes.
Use a native connector when your flow is genuinely standard, volume is modest, and you can adapt your process to the connector rather than the reverse. Walk away when the demo requires the word “workaround” more than twice.
Option 2: iPaaS, and Why Celigo Dominates the NetSuite Ecosystem
Integration platform as a service sits between your systems as a managed middleware layer. Several platforms play here, but in the NetSuite world one name comes up constantly: Celigo. That is not an accident. Celigo was founded by former NetSuite people, its integrator.io platform treats NetSuite as a first-class citizen, and its prebuilt Integration Apps for Shopify, Amazon, Salesforce, and common 3PL scenarios encode years of NetSuite-specific edge case handling.
An iPaaS gives you the middle path. Prebuilt templates get standard flows running quickly, like a connector. But underneath sits a real platform: custom field mappings, transformation logic, branching, scheduling, retry handling, and a proper error dashboard where failed records queue for review instead of vanishing. When your requirements outgrow the template, you extend the flow instead of replacing the architecture.
The trade-offs: subscription costs are meaningful and scale with connections and volume, so a many-endpoint environment carries a real annual platform bill. And “low-code” does not mean “no-skill.” A well-built Celigo environment reflects deliberate design decisions about flow architecture, error handling, and NetSuite record behavior. Poorly built flows work in the demo and fall over during the Black Friday order spike. This is why specialized Celigo integration services exist as a discipline: the platform is accessible, but production-grade design is not automatic.
Use an iPaaS when you have multiple integrations, standard-plus requirements, meaningful data volume, and a preference for monitoring and maintainability over minimum cost. For most mid-market NetSuite customers with three or more connected systems, this is the default right answer.
Option 3: Custom Integration with SuiteScript and SuiteTalk
NetSuite’s own development stack can integrate anything with an API. RESTlets and SuiteTalk (REST or SOAP web services) expose NetSuite records to the outside world. SuiteScript handles logic on the NetSuite side. A developer can build precisely the integration you need, with exactly your business rules, and no platform subscription.
Custom is the right tool in specific situations. Genuinely unusual requirements that no template will ever cover. Very high-volume, latency-sensitive flows where a purpose-built pipeline outperforms generalized middleware. Internal systems with no commercial connector. Or environments with strong in-house development teams that will own the code long-term.
Custom is the wrong tool far more often than it gets chosen. The build cost is only the visible cost. Custom integrations need documentation, monitoring, error handling, and maintenance through every NetSuite release and every API change on the other side, forever. The most common rescue scenario in this category: a custom integration built years ago by a developer who has since left, undocumented, failing intermittently, and understood by no one. That is not an integration. It is a liability with an API key.
Use custom when the requirement genuinely cannot be met any other way, and only with documentation and ownership plans written before the first line of code. Never use custom because it looked cheaper than the iPaaS subscription. It is cheaper the way an unmaintained bridge is cheaper.
The Decision in Practice
Strip away the vendor noise and the choice comes down to four questions.
- How standard is the flow? Standard goes to connectors, standard-plus goes to iPaaS, genuinely unique goes to custom.
- How many integrations will you have in two years? One, a connector may do. Three or more, an iPaaS pays for itself in consolidated monitoring alone.
- What happens when a sync fails? If a missed order costs real money, you need the error visibility and retry handling that connectors rarely provide.
- Who maintains this in year three? If the answer involves a specific person’s name rather than a platform or a partner, redesign.
Note what is not on the list: upfront price. Integration architecture is a total-cost decision. The cheap option that fails silently costs more than every subscription on the market.
Where Integrations Actually Fail
Whatever architecture you choose, the failure points are consistent, and worth designing against from day one.
Duplicate and mismatched records top the list: the same customer created twice because the match logic keyed on email in one flow and name in another. Item mapping is next, especially with kits, matrix items, and marketplace-specific SKUs. Timing issues follow, where inventory syncs lag and channels oversell. And silent failures beat all of them for damage, because an integration that fails loudly gets fixed while one that fails quietly corrupts data for weeks.
A well-designed integration defines the system of record for every entity, handles errors as a first-class requirement, and gets tested against volume spikes and ugly data, not just the happy path. This is the core of what professional NetSuite integration services actually deliver: not the pipe, but the judgment around the pipe.
The Bottom Line
Native connectors for simple and standard. Celigo or comparable iPaaS for the mid-market default of multiple systems and real requirements. Custom for the genuinely unique, with maintenance planned like the long-term commitment it is.
And whichever path you take, decide it deliberately, with someone who has watched all three succeed and all three fail. Integration is the workstream where experience is most obviously priced below its value.
