Systems integration: how to make everything talk

Systems integration means making systems exchange information on their own, without someone in the middle typing the same thing twice. An example: the order placed on the website shows up in the management system, the invoice is issued, the stock is updated and the customer gets a confirmation on WhatsApp. If all of that happens without anyone copying and pasting, the systems are integrated.

In this article, I explain how to recognize that your company needs integration, the most common ways to do it, and the precautions that separate a reliable integration from one that becomes a headache.

Signs your systems need to talk

• The team types the same information in more than one place. The order comes in on the website, someone enters it in the management system (ERP), then updates the delivery spreadsheet.
• The numbers don’t match. Stock in the system says one thing, the online store says another, and nobody knows which is right.
• There’s “the person who exports and imports”. Every day someone downloads a file from one system and uploads it to another — and when that person is away, nobody else knows how to do it.
• The customer is waiting for something that already happened. The payment was confirmed, but the order is only released when someone checks it manually.
• Reports take days. To get an overview of the business, you have to pull data from several places into a spreadsheet.

Each of these signs costs hours of work, opens the door to errors and delays the customer. If this routine lives in spreadsheets today, also read Planilha ou sistema: quando sua empresa precisa mudar (in Portuguese).

The most common integrations

Integration	What it solves
Website or online store with the ERP	Orders, stock and prices always the same on both sides
System with payment methods	A confirmed payment releases the order automatically
System with invoicing	Invoices issued without retyping the sale data
System with WhatsApp and email	Automatic status updates for the customer
CRM (the sales team’s system) with the management system	Sales and operations looking at the same data
App with the internal system	What’s done on the phone shows up in the system right away
System with carriers and the postal service	Tracking and shipping costs without manual lookups

How integrations are done

Native integration

Many off-the-shelf systems come with connectors for the most popular tools. When one exists and does what you need, it’s the fastest path: usually it’s just a matter of configuring it.

Through an API

Most modern systems have an API, an “entry door” that lets another system query and send information in an organized way. It’s the most common and most reliable way to integrate when there’s no ready-made connector — and it lets you apply your business rules, within what the other system’s API offers.

Through webhooks (automatic notifications)

Instead of one system asking the other every so often “did anything happen?”, the source system notifies the other the moment something happens: a confirmed payment, a new order, a new support ticket. That’s what makes the integration practically instant. This automatic notification is called a webhook.

Through files

When one of the systems has no API — still common in older systems —, the exchange can be done with files, generated and read automatically at set times. It’s less immediate, but it works, and it’s much better than someone doing it by hand.

Automation platforms

Ready-made automation tools (such as Zapier, Make or n8n) connect popular systems without coding. They’re great for simple flows. Since they usually charge per run, when the rules get complex, the volume grows or the data is sensitive, a custom-built integration tends to be more reliable and cheaper in the long run.

The precautions that make the difference

Integrating is easy when everything works. What sets a well-built integration apart is what happens when something goes wrong — and something always goes wrong at some point: the other system goes down, the internet drops, a piece of data arrives in an unexpected format.

• No information can be lost. If the other system is down, the information needs to wait in a queue and be sent again when it comes back, instead of simply disappearing. And a periodic reconciliation between both sides catches whatever slipped through.
• No duplicates. If the same information is sent twice, the system needs to recognize it and not create two orders. This happens more often than you’d think: each new attempt to send can repeat something that had already arrived.
• Log everything. Every exchange needs to be logged, so you can know what was sent, when and with what result.
• Alerts. When an integration fails, someone needs to find out before the customer complains.
• Security. Access with keys and permissions, encrypted communication and only the necessary data in transit.
• Documentation. Whoever maintains the system two years from now needs to understand how the integration works.

What drives the effort of an integration

• The quality of the other side’s documentation. If the API has good documentation and a test environment, the integration moves fast; if not, every detail becomes trial and error. Some vendors also charge for access or require a certification process.
• The number of rules. Copying data from one side to the other is simple; transforming, validating and handling exceptions is what takes work.
• Volume and speed. Syncing once a day is very different from syncing thousands of records in real time.
• How many systems are involved. Each additional system is one more point that can change or fail.

If you want to understand how these factors weigh on a project’s budget, I explain it in Quanto custa desenvolver um sistema sob medida? (in Portuguese).

Where to start

1. Map where information is typed more than once. That’s where the biggest gain is.
2. Prioritize by impact. Weigh the gain against the effort: start with the integration that solves the biggest pain with the smallest investment.
3. Check what the systems offer. A ready-made connector, an API, files: that defines the path.
4. Define what happens when something fails before you start, not after the first problem.

How WorkCodes builds integrations

Integration is part of many of the projects we deliver: ERPs, payment methods (including PIX, Brazil’s instant payment system, and cards), WhatsApp, calendars and public databases, among others. We use queues and log every exchange: when one side fails, the information waits and is resent, instead of being lost.

When the challenge is figuring out what to integrate and in what order, our technology consulting helps build the plan. When it’s time to build, we develop the integration or the custom system that connects everything, with the first prototype within a few days and frequent deliveries so you can follow every step. We work with companies remotely.

Get in touch and tell us which systems your company uses today. After an initial, no-strings conversation, you get a proposal with scope, timeline and price within 24 hours.