Integrations and APIs: how to connect your business systems

What an integration is and why it matters

In most companies, information lives in several places: a back-office system, an online store, the invoicing portal, the carrier's platform and a spreadsheet or two. When those systems don't talk to each other, someone has to copy data from one to the other. That manual work is slow, error-prone and depends on the right person being available.

An integration is an automatic connection between two systems so they can exchange information without human intervention. Most are built on an API (application programming interface): a set of rules a system publishes so others can request data from it or ask it to do something, such as issue an invoice or create a shipping label.

You don't need to understand the technical details to make good decisions. What matters is knowing which processes can be connected, what doing it well involves and what to ask before you start.

The most common business integrations

These are the connections companies in Mexico ask for most, and what each one solves:

Invoicing deserves a special mention. In Mexico, CFDI 4.0 invoices are certified through an authorized certification provider (PAC). The PAC validates the invoice and assigns its tax folio; your system only needs to send it the right data and store the response. Doing this well means validating before sending (the recipient's tax regime, postal code and CFDI use), handling cancellations and issuing payment receipts when required.

Syncing: real time or batch

Not every integration needs to work the same way. There are two main approaches:

• Real time. When something happens, the other system finds out right away. For example, the payment gateway tells your store that a charge was approved. That notice usually arrives through a webhook: an automatic message one system sends to another when an event occurs.
• Batch. Information is synced periodically, for example every hour or once a day. It works well for inventory, reports or reconciliations where a few minutes of delay don't affect operations.

You also need to decide which system owns each piece of data. If a product's price can be changed both in the ERP and in the online store, sooner or later you'll have two different prices. The healthy setup is for each piece of data to have a single source, with every other system receiving it from there.

Security is part of the same design. Each service's credentials should be stored outside the code with restricted access, communication should be encrypted, and the webhooks your system receives should be verified to confirm they really come from the provider and not from a third party trying to fake a payment.

What happens when something fails

Every integration will fail at some point: the external service doesn't respond, its API changes, incomplete data arrives or the internet goes down. The difference between a fragile integration and a reliable one is how those cases are handled:

• Automatic retries when the error is temporary, without duplicating the operation (you don't want the same invoice issued twice).
• A log of every exchange so you know what was sent, what came back and when.
• Alerts to the right person when something needs attention.
• A screen to review and reprocess pending operations without calling a developer.

How to plan an integration

Before writing any code, answer a few questions with your team and your developer:

1. Which process do we want to automate, and how is it done today?
2. What data moves, in which direction and how often?
3. Which system is the official source for each piece of data?
4. Does the external provider offer a documented API, a test environment and credentials for us?
5. Who gets notified, and who acts, when something fails?

If your current systems have no API or a very limited one, it may make sense to replace part of them with a system of your own. We cover that in when a custom ERP makes sense. And if key processes still run on spreadsheets, see how to move from spreadsheets to a system.

At ProWeb we treat integrations as part of the project, not an add-on: we review the provider's documentation, test against their sandbox, design error handling and log every exchange so your team has visibility.

An integration isn't finished the day it goes live. Providers update their APIs, the SAT publishes changes to its catalogs and your operation evolves. That's why it pays to plan from the start who will maintain it and how changes will be detected before they affect your customers.