Why API-First ERP Architecture Matters More Than Your Module Choice

Every ERP selection process we have ever observed spends 80% of its time on modules. Does it have multi-currency support? Can it handle the landed cost calculation our logistics team needs? Does the manufacturing routing work the way our operations manager expects? These are real questions. They matter.

But they are not the questions that determine whether your ERP becomes the connective tissue of your operations or a silo that everything else works around. That is determined almost entirely by one thing: whether the platform was designed around its API or whether the API was bolted on after the UI was built. The difference is not subtle. It shows up immediately in the first integration project, and it compounds every year after that.

The integration tax

We got this wrong on the first two projects we ran. We evaluated ERPs on functionality and price, built the integrations, shipped, and moved on. It was only when we were maintaining those integrations 18 months later — rewriting connection code after vendor updates, debugging silent failures, building polling workarounds because webhooks were unreliable — that we understood what we had signed up for.

We now call this the integration tax. It is the cumulative cost — in engineering time, reliability incidents, and delayed automation — that you pay when your ERP does not expose clean, stable, properly versioned REST endpoints. It is not a one-time cost. It compounds. An ERP with a poor API layer that costs $20K less on licensing will typically cost you more than that difference within 18 months in integration overhead alone. Over five years, we have seen the gap reach $80K–$120K on mid-market implementations.

The $54K client in the introduction was not unusual. It was actually below average for the pattern.

Webhooks vs polling — why this distinction matters for finance

This sounds like a technical detail. It is not. It is a financial operations question.

Polling means your system asks the ERP every N minutes: has anything changed? It works. It is also wasteful, introduces latency, and creates load on the ERP server that vendors often rate-limit aggressively. A finance automation pipeline that runs on 5-minute polling intervals introduces up to 5 minutes of lag into every payment approval, every inventory update, every bank reconciliation trigger. That is tolerable for some workflows. For cash flow visibility and AP cut-off, it is not.

Webhooks mean the ERP tells your system immediately when something changes. No lag. No wasted requests. Your automation runs the moment the triggering event happens. For finance operations — invoice approval, payment released, PO confirmed — the difference between a webhook and a 5-minute poll is the difference between a real-time operation and a batch process pretending to be real-time.

Many ERP vendors advertise "event-driven architecture" in their marketing materials. Ask them specifically: which business objects support outbound webhooks? What is the payload schema? What are the retry semantics when the subscriber is unavailable? If they cannot answer all three questions in writing before you sign, assume the answer is "it is polling with a different name."

Business logic buried in the UI

This is the failure mode that is hardest to catch in a pre-sales evaluation, and it has burned us more than once.

In ERPs that were not designed around their API, business logic often lives in the UI layer. Validation rules, workflow triggers, approval routing, auto-population of related fields — all of these run when a user interacts with a form. When you call the same operation via the API, you bypass the UI entirely. The validation does not run. The related fields do not populate. The workflow does not trigger.

You discover this in production, usually at 11pm during a go-live weekend, when an automated invoice creation is successfully acknowledged by the API but the accounting entries are wrong because a field that the UI normally auto-calculates was never set.

True API-first design means the business logic lives in the service layer, not the view layer. The UI calls the same service methods as the API. Both paths are consistent. Ask any ERP vendor you are evaluating: "Does your API call the same service layer as your UI, or does it write directly to the database?" The answer tells you everything.

Rate limits, authentication, and what the brochure skips

OAuth 2.0 support is now table stakes. But the implementation quality varies significantly. We have worked with ERP vendors whose OAuth tokens expire after 30 minutes with no refresh token support — meaning your integration must re-authenticate from scratch on a schedule, and any background process running longer than 30 minutes fails silently. We have seen others where the OAuth implementation only works for user-delegated flows, not service-to-service, making unattended automation impossible without a workaround that stores user credentials.

Rate limits are the other thing nobody puts in the brochure. Odoo Community has no built-in rate limiting on its REST API — which sounds like an advantage until your integration hammers it at peak load and takes down the ERP for other users. Business Central enforces rate limits at 600 requests per minute per environment — which is reasonable for most workflows, but becomes a real constraint if you are running a high-frequency reconciliation process. SAP Business One's Service Layer has per-session connection limits that are not documented in the main API guides.

None of this is a dealbreaker. All of it is something you want to know before you architect the integration, not after. Ask for the API rate limit documentation, the authentication flow diagrams, and the session management specs. If any of those do not exist as standalone documents, build extra time into your integration estimate.

What API-first actually means — the technical reality

Vendors use "API-first" as a marketing term now. It has lost most of its meaning. Here is what it should mean technically, and what we check for:

The client who chose the cheaper ERP

A distribution company came to us 14 months into an ERP implementation. They had chosen a mid-market platform — not Odoo, not Business Central, a regional vendor — that cost $22K/year less than the alternatives they evaluated. The module coverage was genuinely good. The sales demo was impressive. The contract was signed.

The integration work started immediately after go-live. Their warehouse management system needed to sync inventory in near-real-time. Their e-commerce platform needed order data pushed within 60 seconds of checkout. Their 3PL needed shipment confirmations.

The ERP had an API. But it was XML-RPC, not REST. No webhook support — everything was polling. The authentication model required a named user session, not a service account, meaning the integration ran as a real user account with password expiry and 2FA. The schema documentation was a 180-page PDF last updated in 2021. Fields changed between minor releases without notice.

By the time we were brought in, they had spent $45K on integration development and had a fragile, polling-based connector that broke on every ERP update. The fix — re-architecting the integration layer with a middleware queue, building a polling adapter with proper retry logic, and writing a field change detection layer — cost another $28K and four months.

Total integration cost: $73K. License saving vs. the alternative they passed on: $22K over the same period. The math does not work, and it was entirely predictable from the API documentation review. They just never did one.

The ERP module selection conversation is the wrong conversation. The right conversation is: show me your OpenAPI spec, your webhook payload schemas, your versioning policy, and your rate limit documentation. If any of those do not exist, the integration cost is not in your budget.

What to ask before you sign

We run a short API evaluation on every ERP we assess. None of these questions require a technical deep dive — they just require that the vendor can answer them at all:

A vendor who cannot answer these questions before you sign cannot support a modern integration architecture after you sign. That is not a risk to manage — it is a cost to price in.