.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 running WooCommerce as their storefront, already integrated with an inventory system, now bringing NetSuite in as their ERP. 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 e-commerce platform 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 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's something that needs to be caught before it becomes a finance team's reconciliation problem.
5. Data doesn't arrive pre-shaped for the other system
What NetSuite needs and what a storefront like WooCommerce sends are rarely the same shape. Someone has to transform and validate that data in both directions. Do it with one-off scripts 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 — after buffer stock, reservations, minimums — is business logic. If that logic 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. That's a much harder problem to diagnose after the fact than it needs to be.
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.
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 ten 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.
