“Won't a new ERP just be one more system we have to wire into everything else?”
It's a fair question. Integration is key to any project, and it only becomes more complex as the project grows. Every new module, trading partner or reporting tool adds another connection to build, test and keep alive.
But connections aren't the problem. Integration you have to hand-build is.
Why integration is where projects stall
MuleSoft's 2025 Connectivity Benchmark puts numbers to what most of us feel on projects. The average enterprise now runs 897 applications, and only 29% of them are integrated. IT teams spend 39% of their time building custom integrations.
That's a lot of skilled time spent on plumbing instead of improving the business. And it's getting more urgent: AI can only work with data it can reach, and 95% of organisations report difficulty integrating AI into their existing processes.
Every table is essentially its own API
What stood out for me when I started building on Nextworld, an enterprise application platform, is that I didn't have to build the API layer. Every table and logic block you create automatically gets a standard set of endpoints. An external system can insert, update, delete or fetch records, or start a logic block, without anyone writing interface code first.
The part I appreciate most, after years on traditional ERP: calling a table's endpoint runs the same business rules configured over that table. Data arriving through an integration is validated exactly like data keyed in by a user. There's no back door.
Outbound is just as manageable. You define the external endpoint, its authentication (OAuth 2.0, tokens, JWT and others) and how each response code should be handled, and a logic block makes the call. It's configured, not coded.
When an API isn't the right fit
APIs aren't the answer to everything, and Nextworld doesn't pretend they are. Good integration design is mostly about picking the right pattern for each job:
- APIs when another system needs to ask or tell Nextworld something. Request and response, on the caller’s schedule.
- Events when Nextworld needs to tell someone else. A workflow state change or a user-defined event is filtered by rules and routed to a logic block or an external target such as AWS EventBridge. Failed deliveries are retried automatically.
- Webhooks when another system wants to push a notification in. Save the webhook setup and Nextworld generates the URL to give the other system, secured with HMAC or basic authentication.
- Connectors for legacy and on-premise systems. Scheduled batch sync, live read-only views of external data, or triggering logic in the other system. JD Edwards is supported through a gateway appliance that sits behind the firewall.
- File imports for migrations and one-off loads. CSV files with the field mappings suggested for you. Check them before you load.
- MCP for AI agents. Nextworld’s MCP server lets AI assistants read and update records, but only within the permissions of the user they act for.
The skill is in choosing the pattern. The plumbing is already there.
The takeaway
Integration will always be part of an ERP project. What Nextworld changes is the starting point. Instead of a blank page and an interface spec, every table is an API from day one, with events, webhooks and connectors for everything else.
And with Nextworld's MCP server, that same data is reachable by AI agents, under the same security rules. That's a good position to start from.
Worried a new platform means another integration headache? Get in touch with VMG Labs and we'll talk it through.
Sources
- Nextworld documentation: Interoperability (table and logic block endpoints, outbound endpoints, events, webhooks, connectors, file import)
- Nextworld documentation: MCP server
- Nextworld: Platform overview
- Salesforce / MuleSoft: 2025 Connectivity Benchmark (897 applications, 29% integrated, 39% of IT time, 95% AI integration difficulty)
