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

ERP selections tend to spend nearly all their 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 system everything else connects to 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

The cost shows up late. You evaluate ERPs on functionality and price, build the integrations, ship, and move on. Eighteen months later someone is maintaining those integrations: rewriting connection code after vendor updates, debugging silent failures, and building polling workarounds because the webhooks are unreliable.

Call it the integration tax: the engineering time, incidents and delayed automation you pay for when your ERP does not expose clean, stable, properly versioned REST endpoints. It isn't a one-time cost. It compounds, and a $20K licensing saving can be gone within 18 months in integration overhead alone.

Webhooks vs polling: why finance should care

This sounds like a technical detail. It is really a finance 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 and 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 events such as an approved invoice or a released payment, 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.

In ERPs that were not designed around their API, business logic often lives in the UI layer. Validation rules, workflow triggers, approval routing and auto-filled fields all run when a user works in 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. Some ERP vendors issue OAuth tokens that expire after 30 minutes with no refresh token, so your integration has to re-authenticate on a schedule and any background process that runs longer fails silently. Others support OAuth only for user-delegated flows, not service-to-service, which makes unattended automation impossible without a workaround that stores user credentials.

Rate limits are the other thing nobody puts in the brochure. A self-hosted Odoo server has no built-in rate limiting on its external API, which sounds like an advantage until your integration hammers it at peak load and slows the ERP for everyone else. Business Central online publishes request-rate and concurrency limits for its APIs. They are reasonable for most workflows and become a real constraint for a high-frequency reconciliation job.

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 should mean technically

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:

How the cheaper ERP ends up costing more

Take a distribution company that picks a regional mid-market ERP because it costs $22K a year less than the alternatives. The module coverage is good, the demo is impressive, and the contract gets signed.

Integration work starts right after go-live. The warehouse system needs inventory synced in near real time, the online store needs orders pushed within 60 seconds of checkout, and the 3PL needs shipment confirmations.

The ERP has an API, but it is XML-RPC, not REST. There are no webhooks, so everything polls. Authentication needs a named user session instead of a service account, so the integration runs as a real user with password expiry and 2FA. The schema documentation is a 180-page PDF that hasn't been updated in years, and fields change between minor releases without notice.

Every connector built on that foundation is fragile and breaks on each ERP update. Fixing it properly means a middleware queue, a polling adapter with real retry logic and a layer that detects field changes, and that rebuild takes months.

Add up the first connector and the rebuild, and the integration bill can pass the license saving it was meant to protect. All of it was predictable from an hour with the API documentation.

Module selection is the wrong conversation. Ask to see the OpenAPI spec, the webhook payload schemas, the versioning policy and the rate limit documentation. If any of those don't exist, the integration cost isn't in your budget.

What to ask before you sign

We run a short API evaluation on any ERP we assess. None of these questions needs a technical deep dive. The vendor just has to be able to answer them:

A vendor who cannot answer these questions before you sign cannot support a modern integration architecture after you sign. Treat that as a cost to price in, not a risk to manage.