API integration: website, CRM, ERP, and invoicing connected.

An API (application programming interface) is the door a piece of software opens to others: it defines which data can be read or written, and in what format. Most recent software has one, often a REST API.

API integration uses these doors to move information between your systems. It rests on three building blocks:

• a trigger: an event (an order created, a quote signed) signaled by a webhook, or a sync at a set time;
• a mapping: translating fields from one system to the other (SKUs, units, VAT, statuses);
• a log: a record of every exchange, successful or not.

The result: data entered once, correct everywhere, and a team that stops bridging systems by hand.

Start with the flow someone already retypes every day. It’s easy to spot: an Excel export followed by data entry, an email forwarded so someone else can retype it, a list kept up to date in two tools.

In small businesses in wholesale and distribution, manufacturing, and services, the same flows keep coming up:

• website and ERP: orders and customers to the ERP, stock and prices to the site;
• CRM and invoicing: the signed quote becomes an invoice, and the payment flows back to the sales rep;
• forms and CRM: every inquiry arrives linked to the right contact;
• banking and accounting: payments matched to invoices.

A good first flow is frequent, easy to check, and visible: the payoff shows within a few weeks, and the same foundation serves the next ones.

Integration platforms (iPaaS tools like Zapier, Make, or n8n) connect common software without writing code. They suit simple, low-volume flows: a form that creates a contact, a notification in Microsoft Teams.

They hit their limits as soon as the rules get complicated (customer-specific pricing, different units, special cases), volumes grow, or a system isn’t in their catalog. The subscription rises with the number of operations, and the logic stays locked inside the tool.

A custom connector, or a thin integration layer (middleware) between your systems, costs more up front but follows your rules exactly, handles the load, and belongs to you. In practice, I often mix the two: a platform where it’s enough, code where precision is needed. The choice is made flow by flow, during the audit.

It’s the most common worry, and rarely a real obstacle. Software without an API almost always opens another door:

• file exports and imports (CSV, Excel, XML), which can be scheduled at set times;
• a database you can read, and sometimes write to, with the vendor’s permission;
• EDI, already in place at many distributors and manufacturers;
• as a last resort, a bot that replays clicks on the screen (RPA), which is more fragile.

The connector translates these exchanges into a format your other software understands. Your ERP stays in place, your team keeps its habits, and the day you replace it, only the connector needs adapting.

I check this on the very first call, so you know up front, with no commitment, whether the connection is possible and how.

Let’s be frank: most exchanges between systems don’t need AI. When two systems have an API and clean data, a mapping rule does the job faster, cheaper, and with no risk of misinterpretation.

AI becomes useful where something needs reading or understanding:

• a PDF purchase order or invoice whose layout changes from one supplier to the next;
• an email in the sender’s own words, with the customer, items, and date to pull out;
• a hand-typed description that has to be matched to the right SKU;
• a likely duplicate that strict rules can’t see.

In these cases, AI extracts the information and hands it to the connector, and the rules check the rest. Anything it isn’t sure it understood is flagged, never written silently. Reading orders and invoices received by email falls under business process automation; giving your team an assistant that queries your software is AI integration.

You judge an integration on the day something goes wrong. Four points make the difference:

• Access: OAuth2 or dedicated keys for authentication, permissions limited to what’s strictly needed, secrets kept out of the code.
• The log: every exchange is recorded with its content and result. You know what went through, when, and why a transfer failed.
• Error recovery: if a system doesn’t respond, the transfer is retried; if it fails again, it’s set aside and an alert goes out. Nothing gets lost.
• Documentation: flows, mappings, access, and the recovery procedure are written down, in your name.

The code, the accounts, and the documentation belong to you. You’re not tied to anyone: another developer can take over the integration, and when a vendor changes its API, the update is limited to a single connector.