The ERP Developer Tax: Why Integrating with NetSuite, Acumatica, and Fishbowl is an 'Onboarding Nightmare'
Source: Dev.to
The Problem
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 receive a single Client ID and Shared Secret.
- The app is recognized throughout the platform’s entire ecosystem.
- When a new customer signs up, you send them through a streamlined OAuth consent flow.
It’s clean, modern, and 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 is the biggest frustration for developers entering the ERP ecosystem. It creates an archaic workflow that kills onboarding conversion and forces SaaS companies to maintain massive, sensitive databases of client secrets.
Why It Exists
The fundamental problem isn’t technical capability; it’s a difference in ecosystem philosophy.
- ERP world vs. modern PaaS: ERP platforms largely function on a model of decentralized, local sovereignty.
- No central “Developer Center”: When you develop for Acumatica, NetSuite, or Fishbowl, there is no place to register your integration once. Your application is a stranger to every single installation.
Consequences
- No “one‑click” setup.
- No global “Connect to NetSuite” button that takes the user to a universal auth screen.
- Registration is manual and per‑instance. For every new customer you must repeat the onboarding steps.
Platform‑Specific Workflows
| Platform | Admin Action | Result |
|---|---|---|
| NetSuite | Admin (standard users lack permission) navigates to Integration Records, creates a new record for your app, copies the generated Consumer Key and Secret, and pastes them back into your onboarding flow. | You now store a unique NetSuite secret for that customer. |
| Acumatica | Admin goes to Connected Applications (SM303010), registers your app by name, and receives a unique Client ID and Shared Secret scoped to that Acumatica site/tenant. | Another unique credential set to manage. |
| Fishbowl (desktop) | Admin logs into the physical server, opens Integrated Apps, clicks Approve for your specific appID after your app sends an initial request (which is blocked until approval). | Session‑token based, requiring manual approval per customer. |
Result: If you have 500 customers using your NetSuite integration, you’re managing 500 unique sets of credentials. This decentralized mess is an operational nightmare, a conversion killer, and a major security risk.
The Real‑World Impact
- Support overload: Every unique credential set must be stored, rotated, and troubleshooted.
- Onboarding friction: Clients receive long, complex PDFs (“Guide to Getting Started with our NetSuite Integration”).
- Security concerns: Storing thousands of secrets in a single database creates a high‑value target.
Common Developer Complaints
- “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.”
Why ERP Platforms Don’t Adopt a Global Model
Security Sovereignty & Liability
- ERP data is the single most sensitive asset a business owns.
- Decentralized registration lets the ERP vendor say: “The integration handshake happened completely within your own instance; if something goes wrong, you are the one who explicitly allowed it.”
- This shifts liability directly to the customer’s CFO.
Private‑Cloud / On‑Prem Challenges
- Many ERP components are installed on‑premises (Fishbowl) or in private clouds (Acumatica, NetSuite private offerings).
- A global OAuth model would require every instance—often behind deep corporate firewalls—to “phone home” to a central authority for each request.
- Enterprises in regulated industries (healthcare, finance, defense) typically block that traffic.
Our Approach at Aurinko
We’re not trying to change how ERPs work; we’re trying to reduce the burden on developers.
- Unify decentralized tenant OAuth registrations behind a single management layer.
- Streamline the resulting auth flows so developers interact with one consistent API, while each ERP instance still retains its local credentials.
- Provide tooling (dashboards, secret rotation, audit logs) that removes the need for SaaS companies to maintain massive, sensitive credential databases themselves.
Goal: Let you focus on building value‑adding features, not on juggling hundreds of unique client secrets.
TL;DR
- Modern SaaS platforms offer a single‑click, global OAuth experience.
- ERP platforms enforce instance‑specific, manual credential creation.
- This creates massive operational, security, and conversion challenges for developers.
- Aurinko is building a solution that centralizes management while respecting each ERP’s sovereignty, dramatically simplifying the “ERP Developer Tax.”
If you’re currently wrestling with 100+ unique Client IDs and Secrets across a fragmented customer base, we’d love to talk about how our platform can help.
oper 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.
[Read more about Aurinko's Dynamic API](#)