The dispatch system they had built in-house worked fine. The trouble came on Friday afternoons: someone exported an Excel file from the ERP, someone else matched it against the online store's orders, and a third person uploaded the payment batch to the bank's portal. One Friday the same file went up twice, and 14 suppliers got paid twice.
Systems integration is what prevents that Friday. When your custom software talks directly to the ERP, the e-commerce platform and the bank, data moves between them without anyone copying it, and errors show up in a log instead of on the bank statement. "We'll connect it through an API" is only the start of the conversation. You still have to pick a pattern for each flow, find out what the vendor of the other system actually provides, and agree on what happens when something breaks, because at some point it will.
The examples below apply to any ERP. At the end there's a concrete case with SAP Business One and with JD Edwards on AS/400.
Four ways to integrate systems
Nearly every business integration falls into one of these four patterns. A single project usually ends up using two or three of them.
| Pattern | How it works | When it fits | What to watch |
|---|---|---|---|
| REST API (direct call) | Your software calls the other system and waits for the answer | Checking stock or price on the spot, creating an order | Response times, rate limits, what to do when the other side doesn't answer |
| Webhooks | The other system notifies your software when something happens | A payment approved, a new order in the store | Checking the notification is genuine, handling the same notification twice without duplicates |
| Message queues | Messages wait in an intermediate queue and get processed when the target is ready | High volumes, systems that go down or have maintenance windows | Messages that keep failing, processing order |
| Scheduled files | A file (CSV, TXT, XML) is generated and another process picks it up at a set time | Older systems with no API, bank payment batches, overnight loads | Duplicate or incomplete files, who checks when the job didn't run |
A well-controlled nightly file is more reliable than a badly designed API. The useful question is how fresh the data needs to be. If a salesperson has to see real stock while quoting, you need a live call. If accounting reviews sales the next morning, an overnight load is enough and easier to maintain.
What to ask the other system's vendor
Get these answers in writing before you estimate anything. They save weeks.
- API documentation, ideally in OpenAPI format, and a test environment with dummy data.
- The authentication method. Server-to-server integrations usually rely on OAuth 2.0 with the client credentials flow (RFC 6749) or an API key. Ask how credentials are rotated and who can issue them.
- Usage limits: how many calls per minute it accepts and what it returns when you go over. The standard answer is HTTP status 429, sometimes with a header telling you how long to wait (RFC 6585).
- If it offers webhooks, how it signs them and whether it retries when your system doesn't respond.
- A technical contact. A generic support inbox is no help when the integration is down.
Chilean banks add a wrinkle. The Open Finance System created by the Fintec Law will standardize APIs for account information and payment initiation, but the CMF (Chile's financial regulator) pushed its start date to July 2027. Until then, each bank has its own channel for business clients (an API, a payment batch file format or something else). Ask your account manager what they offer before you design anything.
Authentication and data in transit
Treat the integration like any other user, with its own rules.
- Create a dedicated service account for each integration, with the minimum permissions. If it only creates orders, it shouldn't be able to void invoices.
- Keep credentials in a secrets vault, never in the code or in a config file inside the repository.
- Always use HTTPS, including inside the internal network.
- For webhooks, check each notification's signature before processing it. If the sender doesn't sign, at least restrict which addresses you accept calls from.
If personal data flows through the integration (customers, employees, suppliers who are individuals), keep Law 21.719 in mind. Its effective date is still December 1, 2026. A bill that would push it to October 15, 2027 has passed the Senate but is still in the Chamber of Deputies. For an integration, the practical move is to send only the fields the other system needs and keep a record of what data left, where it went and when.
Error handling: decide up front what happens when it fails
An integration nobody designed for failure ends with someone checking it by hand every morning. These are the rules worth agreeing on at design time:
- Retries with increasing waits. If the ERP doesn't answer, wait a few seconds and try again, then wait longer. Retrying instantly and without limit makes an outage worse.
- Idempotent operations. Sending the same order or payment twice must not create two records. The fix is a unique ID per operation that the target system checks before creating anything. That alone would have prevented the double payment in the opening story.
- An error inbox. Messages that fail several times need to land somewhere visible, with the reason, so a person can review and resend them. If they disappear into a log nobody reads, you'll hear about it from a customer.
- Validation at the door. Reject a malformed tax ID or a product that doesn't exist early, with a message that says which field failed.
Monitoring: find out before the customer does
If nobody monitors the integration, the first sign of a failure is usually a customer complaint. At a minimum you want:
- A record of every operation, with time, result and an ID to trace it end to end.
- Alerts when the error rate rises or when a scheduled job didn't run on time. People forget that second one. The nightly file that never arrived throws no error; it just isn't there.
- A simple dashboard with today's activity: how many orders came in, how many failed and how many are pending.
Case: SAP Business One and JD Edwards on AS/400
In SAP Business One, the modern way in is the Service Layer. According to SAP's official guide, it's an HTTP and OData based API that exposes SAP Business One business objects (business partners, items, orders, invoices) and runs on SAP HANA and also on Microsoft SQL Server from version 10.0 PL01. For an online store, that means creating the sales order in the ERP and checking stock per warehouse without touching the database. If you're weighing what to integrate against what to build separately, we covered it in when to build custom on SAP Business One.
With JD Edwards on AS/400 (now IBM i), people often assume there's no way in. There is. IBM i includes an integrated web services server that lets you publish ILE programs, RPG for example, as web services other systems can call. In many companies the setup that works is mixed: web services for live lookups (stock, order status) and scheduled files for bulk loads like the product master. If your JDE needs some care before you integrate it, see maintaining JD Edwards on AS/400 without migrating.
The advice is the same in both cases: don't write directly to the ERP's tables. Going through the layer the vendor provides keeps the system's validations in place and avoids surprises at the next upgrade.
Frequently asked questions
How long does a systems integration take?
It depends mostly on how good the other system's documentation and test environment are. An integration with a well-documented API can be ready in a few weeks. One with an older system that has no API usually takes longer, because you first have to work out how to expose the data.
Is an API better than a file load?
If you need the data right away, use an API. If having it the next day is fine and the volume is large, a well-controlled scheduled file is usually simpler to run.
Who maintains the integration after go-live?
Put it in the contract. APIs change versions, credentials expire and systems get upgraded. Without an owner, the integration degrades and nobody notices.
Connect your systems and drop the Friday spreadsheet
At Disrupsoft we build custom integrations between your systems, third-party platforms and your own interfaces, with secure APIs, SSO/MFA and automation with Power Automate. We start by analyzing your current systems and processes so each flow gets the right pattern. If you want to stop moving data by hand, let's talk about integrating your systems.
