New

The Erp Developer Tax: Why Integrating With Netsuite, Acumatica, And Fishbowl Is An "onboarding Nightmare"

Ask any developer who has built integrations for Stripe, GitHub, Shopify, or Salesforce, and they’ll tell you it’s usually a great experience. You register your app once in a central developer portal, you're issued a single Client ID and Shared Secret, and you are done. Your app is recognized throughout that platform's entire ecosystem. When a new customer signs up, you just send them through a streamlined OAuth consent flow. It’s clean, it’s modern, and it works.

Now, ask any developer who has had the "pleasure" of integrating with major ERP players like NetSuite, Acumatica, or Fishbowl. Be prepared to see a pained expression. Welcome to the parallel dimension of decentralized, instance-specific onboarding, otherwise known as the "ERP Developer Tax."

This single issue represents the biggest frustration for developers entering the ERP ecosystem, creating an archaic workflow that kills onboarding conversion and forces SaaS companies to maintain massive, sensitive databases of client secrets.

Let's break down exactly what this situation looks like, why it exists, and how we are trying to fix it at Aurinko.

The Pain: One Client ID, Infinite Problems

The fundamental problem isn't technical capability; it's a difference in ecosystem philosophy. The ERP world, unlike modern PaaS, largely functions on a model of decentralized, local sovereignty.

When you develop for Acumatica, NetSuite, or Fishbowl, there is no central "Developer Center" where you can register your integration once. Instead, your application is a stranger to every single installation.

You can't build a "one-click" setup. There is no "Connect to NetSuite" button that takes the user to a global auth screen.
Registration is manual and per-instance. For every new customer that signs up for your integration, the "Onboarding Guide" becomes required reading.

The "Rite of Passage" on Major Platforms

NetSuite: The user (typically an Admin, as standard users lack permission) must manually go to the "Integration Records" screen, create a new record for your app, copy the Consumer Key and Secret that are uniquely generated, and paste them back into your onboarding flow. You now have a database with one NetSuite secret. When your next customer signs up, you get to do it again.
Acumatica: It’s a similar story. The admin navigates to the "Connected Applications" (SM303010) screen. There, they register your app by its name, and the system generates a unique Client ID and Shared Secret specific only to that Acumatica site and its tenants.
Fishbowl: The traditional desktop product (Fishbowl Advanced) is even more extreme. Authentication is session-token-based. Your app sends an initial introduction request, which is immediately blocked by the server. A human admin must then literally log into the physical server, open the "Integrated Apps" tab, and click an "Approve" button to allow your specific appID access.

This means if you have 500 customers using your NetSuite integration, you are managing 500 unique sets of NetSuite credentials. This decentralized mess is an operational nightmare for your support team, an absolute conversion-killer for your onboarding flow, and a major security risk for your organization.

The Consensus: We’re All Complaining About This

If this sounds incredibly frustrating, that's because it is. You don't have to look far in developer communities to see the fallout. Forums for Acumatica, the NetSuite sub-reddit, and various developer Discords are full of posts lamenting the onboarding friction.

The #1 complaint is the total lack of onboarding control. Instead of providing a modern web experience, developers are reduced to sending clients complex 10-page setup PDFs ("Guide to Getting Started with our NetSuite Integration").

The common refrains include:

"Why can't I just register my app and have clients authorize it like they do with QuickBooks Online?"
"My client's IT admin has been trying to set up the OAuth for three days. How can I possibly support this?"
"I’m literally paying the NetSuite SDN fee just to try and automate this local setup, and it’s still ridiculous."

The "Why": Sovereignty and Legacy

So, if this is universally hated, why don't platforms like Acumatica or NetSuite just modernize and move to a global model? The reasons are rooted in the unique requirements of the ERP market:

Security Sovereignty and Liability: ERP data is the single most sensitive asset a business owns. Moving from local registration to a global registration means the ERP vendor would have to operate a centralized, trusted authority that acts as the source of truth for all client authorizations. The current decentralized model allows the ERP to say: "The integration handshake happened completely within your own instance; if something goes wrong, you are the one who explicitly allowed it." It’s an effective way to shift liability directly to the customer's CFO.
The Private Cloud/On-Prem Challenge: Modern SaaS like Salesforce lives entirely in the public cloud. However, major ERP components can be installed "on-premises" (Fishbowl Advanced) or in "private cloud" environments (Acumatica, NetSuite's private offerings). For these systems, a global OAuth model would require every single instance, including those behind deep corporate firewalls, to "phone home" to a central authority to validate a global Client ID and Secret every time a request is made. Many enterprise customers (healthcare, finance, defense) simply will not allow this level of traffic.

Can We Make the Management Less Painful?

Are you currently dealing with the nightmare of managing 100+ unique Client IDs and Secrets across a fragmented customer base?

At Aurinko, we’re trying to simplify this reality. We realize that as long as ERPs prioritize local sovereignty, the manual setup steps for ERP admins are here to stay. However, we believe the management of those connections shouldn't fall entirely on your shoulders.

We are working on ways to unify these decentralized tenant OAuth registrations and streamline the resulting auth flows. Our goal isn't to change how the ERPs work, but to change how much of that complexity you have to touch.

If you’re feeling the weight of the "ERP Developer Tax," we’d love to hear how you’re handling it today—let’s talk and see if we can make the process a little less manual for everyone.