The short answer
To integrate systems, use the API of your ERP and the other systems whenever it exists, with a webhook when one side needs to know right away that something changed. Files and an intermediate database work when there is no API, and a bot that mimics clicks is the last resort. Before choosing, define which system is the source of truth for each piece of data.
The way you integrate is only half the job. The other half is what happens when something goes wrong: the target system is down, a record is rejected, the same sale is sent twice. A well-built integration handles failures, reprocesses without duplicating, protects credentials and alerts someone when it stops.
What are the ways to integrate systems
There are five main ways to get two systems to exchange data. The choice depends on what each system offers, the volume of records and how much delay the operation can tolerate.
| Method | How it works | Advantages | Watch out for |
|---|---|---|---|
| API | One system calls the other through a documented interface to read or write data | It is the standard path, secure when well configured, and lets you validate each record on the spot | Depends on the vendor offering the API, on call limits and on version changes |
| Webhook | The source system automatically notifies the target when something happens | Data in near real time, without asking all the time whether something changed | The notice is lost if the target is down, so it requires reconciliation and resending |
| File | Periodic export in CSV, XML or a similar format, read by the other system | Simple, works with old systems and is easy to audit | Delay between exports, formats that change without notice and the risk of reading the same file twice |
| Intermediate database | The systems write to and read from a database or table agreed between them | Useful when there is no API and the volume is high | Ties the systems to the database structure, and touching the database of an off-the-shelf system directly can compromise vendor support |
| RPA (screen bot) | A bot mimics a person clicking and typing in the interface | Works when no other means exists | Breaks with every screen change, is slow and hard to monitor |
In practice, a mature integration combines methods: an API to write, a webhook to notify and a periodic reconciliation to catch what slipped through. When the current system offers no reasonable means, the question becomes whether it is worth keeping, the subject of the guide on how to modernize a legacy system.
What to assess before integrating your ERP with other systems
Many integration problems are born before the first line of code, from a question nobody asked. This is the assessment worth doing before choosing how to integrate:
- Documentation. Does the system have a documented API? A test environment? Who provides access and how long does that take? Integration without a test environment becomes testing in production.
- Volume. How many records per day and at what peaks. Ten orders a day and ten thousand call for different designs.
- Frequency. Does the data need to arrive instantly, every hour or once a day? Real time has a cost and is only worth it where the operation needs it.
- Source of truth. For each piece of data, which system is in charge. We cover this in the next section.
- Identifiers. How to know that customer 123 in the ERP is the same customer in the CRM. Without a common key, the integration duplicates records.
- Limits and contracts. Call limits, vendor charges for API access and what the contract allows you to do with the data.
- Owners. Who in the company is responsible for each system and who will be notified when something fails.
In the initial study of our projects, we map what each system allows and, when there are limitations, we explain the alternatives and the impact of each one before we start.
Who is the source of truth for each piece of data
When two systems store the same data, you need to decide which one is in charge. The product price comes from the ERP, the customer's contact details may come from the CRM, the delivery status comes from the carrier's system. Without this definition, each system corrects the other, and the team ends up checking which version is right.
The practical rule is that each piece of data has a single place where it is created and changed. The other systems receive copies and do not edit them, or, if they do, they send the change back to the source through an agreed path. That is what lets data be entered once and reach the other systems with no retyping and no two versions of the same information.
This decision sometimes reveals that the problem is not integration but that a system no longer fits the process. The guide on off-the-shelf or custom software helps with that assessment.
How to handle failures and reprocess without duplicating
Every integration will fail at some point: the other system goes down, the network fluctuates, a record arrives with an invalid field. What separates a reliable integration from a fragile one is what happens at that moment.
- A queue instead of a direct call. The record goes into a queue and is sent from there. If the target is down, it waits instead of getting lost.
- Retries with increasing intervals. Try again right away and then with a longer wait, without overloading the other system with repeats.
- Idempotent sending. Each record carries a unique identifier, and the target recognizes when it receives the same submission twice. That way reprocessing does not create a duplicate order.
- Data errors kept apart from technical errors. A system being down is solved by retrying; an invalid tax ID is not. Rejected records go to a pending list with the reason, for someone to fix.
- Periodic reconciliation. A check that compares source and target and points out what was left behind, because no mechanism catches everything.
Security in systems integration
An integration is a door between two systems and should be treated as such. The basic precautions:
- Credentials outside the code. API keys and passwords are kept in a vault or protected variables, with periodic rotation.
- Least privilege. The integration user accesses only what it uses. If it only reads orders, it cannot delete customers.
- Protected channel and signed calls. Encrypted traffic and, for webhooks, verification that the notice really came from the source system.
- Personal data with a purpose. Only what the target needs is transmitted, in line with Brazil's data protection law (LGPD), and every transfer is logged.
In the beacon monitoring project, the presence figures go out through a signed API and are consumed by the dashboards the health unit already used, instead of forcing the team to open yet another system.
Monitoring: how to know the integration has stopped
The worst integration failure is the silent one: it stops on a Friday and someone notices on Monday, when the inventory does not add up. Monitoring means knowing before the customer does.
- Absence alert. If no record went through in a period when records always do, someone is notified.
- Pending items dashboard. A visible error queue, with the reason and age of each stuck record.
- Log of every submission. What went out, when and with what response. That is what lets you investigate a discrepancy without guessing.
- Alert owner. An alert that goes to everyone reaches no one. Each type of failure has an owner.
Integrating systems is one of the fronts of our work in automation and artificial intelligence and in custom software. From our first retail projects, integrated with ERPs and marketplaces, to the front desk of the patient management system, integrated with CAD-SUS and the CNS (Brazil's national health card), the lesson repeats: an integration is only done when someone knows, without having to ask, that it is working.