.svg)
There's a question that comes up in almost every NetSuite integration conversation we have: "Both systems have APIs — why can't we just connect them directly?"
It's a fair question. Technically, you can connect NetSuite to another system with a direct, point-to-point API call. We've just seen what happens after, enough times, to know why most businesses end up needing a proper NetSuite integration platform instead.
The clearest version of this conversation we've had recently was with a retail client bringing NetSuite in as their ERP alongside an existing customer-facing storefront platform. Their operations lead asked the direct question early on: "Is it via the API, or direct integration, or is there any middleware you are having?" He'd already lived through a version of this — custom bridges built to patch gaps in an existing integration — and wanted to know if he was about to do that again.
That conversation is a good summary of the ten things that, in our experience, actually go wrong when two systems are connected through direct API-to-API integration, without anything managing what happens in between.
1. NetSuite has no native queue — someone has to build one
This is the one people don't expect. NetSuite doesn't queue incoming requests. If you're connecting directly, the queue has to live somewhere — either in the source system or in NetSuite itself. In practice, "direct" integration was never actually direct; it just meant nobody had decided yet where that logic would sit.
2. NetSuite's concurrency limits will fail transactions you didn't expect to fail
NetSuite is a shared, multi-tenant SaaS environment, and Oracle governs it accordingly — a fixed number of parallel API calls at a time. Send more requests than that limit allows and the extras simply fail. If nothing is managing that on the way in, the burden of catching and retrying those failures falls on whichever system is sending the data, which is rarely built for that job.
3. Retries end up being a person's job, not a system's job
Without a retry mechanism in the middle, a failed transaction just sits there until someone notices — usually a customer complaining, or a warehouse team finding a mismatch. We'd rather that be an automatic retry policy, with proper backoff and a dead-letter path for anything that still can't resolve itself, than a task on someone's to-do list.
4. Duplicates aren't rare — they're routine
Webhooks fire twice. Networks drop mid-request. Someone double-clicks. Any one of these can create a duplicate order or duplicate stock movement if nothing is checking for it before it hits NetSuite. This isn't an edge case worth documenting and hoping for the best — it needs an idempotency rule: a retry should be allowed to repeat the transport, but it must never be allowed to repeat the business transaction.
5. Data doesn't arrive pre-shaped for the other system
What NetSuite needs and what a source system sends are rarely the same shape. Someone has to transform and validate that data in both directions — ideally into a stable, canonical event structure so that changes on either side are absorbed at the edge instead of rippling through the whole integration. Do it with one-off scripts instead, and every future change to either system means going back into code. That's a real cost, and it's one clients often don't see coming until the second or third change request.
6. "In stock" and "available to sell" are not the same number
This came up directly in the conversation and it's one of the more important points: an API can tell you a quantity, but whether that quantity is actually sellable is business logic — on-hand stock, minus committed and non-sellable status, minus safety or channel buffer, adjusted for location rules. If that calculation isn't centralized somewhere, every connected channel ends up making its own assumption about it, and that's how businesses oversell stock they don't have.
7. When something breaks, you need to know why quickly
"The webhook didn't fire." "The order never made it across." Without logging and traceability sitting between the two systems, these failures are invisible until someone downstream notices something's wrong. Good observability means a clear drill path — from a dashboard showing overall flow health, down to the specific message, its processing stage, its payload, and the exact reason it failed — not a search through source code or database logs after the fact.
8. Most integrations run both directions, which doubles the fragility
Orders typically flow one way, stock and pricing the other. Each direction has its own failure points, its own transformation rules. Treating that as two separate custom-built connections, rather than one governed process, is how the maintenance burden compounds over time.
9. Scripts that solve today's problem become tomorrow's constraint
This is the pattern we see most often: a direct integration works fine at launch, held together by scripts written for the requirements at the time. Then the business grows, adds a channel, changes a process — and every adjustment means opening that code again. One client on this same call put it plainly: "we cannot go with that always — there will be customization based on the business requirement." That's the crux of it. The business keeps changing; hard-coded integrations don't.
10. Operational visibility shouldn't require asking a developer
With a direct integration, the health of the connection usually lives in logs only a developer can read. We think that's backwards — the people who actually own the process day-to-day should be able to see what's syncing, what's failed, and what's pending, without needing someone else to go check.
Direct API vs. External iPaaS vs. a Governed Integration Platform
Once a business accepts that something has to manage queuing, retries, and monitoring, the real decision isn't "API or no API" — every option still uses the same underlying APIs. The decision is where that operational responsibility lives: inside custom code the business now owns, inside a separate third-party platform, or inside a governed layer built natively around the ERP itself.
The road-and-traffic-control comparison holds up well here: the API is the road connecting two systems — cars can travel on it either way. What a governed platform adds is the traffic management and monitoring layer: the queuing, the signals, the incident response. Without it, cars can still get through, but congestion, accidents and failed deliveries become far harder to handle at any real volume.
It's also worth being honest about what a governed platform does not do. It doesn't make a poorly designed integration successful on its own — the business and the implementation team still have to agree on data ownership, field mappings, inventory calculations, and who's responsible for exceptions. What the platform changes is whether those decisions are visible and controlled, or buried in code nobody can see.
Eight scenarios worth testing before trusting any integration approach
Whichever route a business takes — direct API, external iPaaS, or a governed platform — this is the honest test of whether it will actually hold up in production. Before going live, ask to see each of these handled, not just a successful API call:
If all eight are demonstrably handled, whatever approach is being proposed deserves serious consideration. If a demo only shows successful calls under ideal conditions, it's a connector — not an integration platform.
What building this yourself actually takes
None of this means custom development is impossible — an experienced team can build any of this from scratch, since the underlying systems expose the necessary APIs and event mechanisms either way. The honest question is how long it takes to get there, and what it costs to keep it there. As a general planning range for a business with a handful of real touchpoints — customers, orders, payments, returns, and inventory — a basic direct connector typically takes somewhere around 6–10 weeks; a genuinely reliable production integration closer to 12–20 weeks; and a full replacement for a governed platform's capabilities, including monitoring, replay, and reconciliation, more like 4–8 months. That assumes an experienced team, clear requirements, and stable APIs — product ownership questions, payment and refund rules, and inventory availability logic can easily extend it.
The fairer comparison, either way, isn't upfront development cost. It's total ownership: custom development plus infrastructure, monitoring, support, and every future change, weighed against a platform's subscription and implementation cost plus governed support. One of those costs is visible on day one. The other tends to show up gradually, a maintenance ticket at a time.
What we've built because of this, not the other way around
We didn't start with a platform and go looking for reasons to justify it. We started by running into these problems repeatedly on real implementations, and built a native NetSuite integration platform — we call it the Control Tower — to handle them consistently instead of solving each one from scratch on every project.
In practice, on a live deployment, that looks like: tens of thousands of integration messages processed daily at a success rate in the high 90s, with the remainder automatically queued, retried, or flagged rather than silently lost; visibility into how much of NetSuite's concurrency limit is being used at any moment; scheduled sync jobs running independently with their own retry logic; and a searchable log of what actually happened, available to the business — not just to whoever wrote the integration.
None of that is unique to us — it's the set of problems any serious NetSuite integration eventually has to solve. The only choice is whether you solve it once, deliberately, or piece by piece, after something breaks.
