API integrations: connecting your management system, CRM, website and other software

An API integration is an automatic link between two pieces of software: when something happens in one, say an order arrives from your website, the other receives the data and records it without anyone retyping it. The API is the “door” each system provides for exchanging data in a controlled way. Connecting management software, CRM, e-commerce, payments and invoicing is almost always possible; what varies is how well documented the systems are, how many flows you need and how reliable they have to be.

APIs explained without jargon

Think of a service counter: you don’t walk into a company’s warehouse, you ask at the counter and get what you need, according to clear rules. An API works the same way. Your online shop doesn’t read the management system’s database directly: it asks “create this order” or “give me the availability of this product”, and the management system replies in an agreed format.

An integration is a set of these requests put in order to automate a process: who calls whom, with what data, at what moment, and what to do if something goes wrong.

Why business software stays disconnected

It’s rarely a decision. Tools get added one at a time: first the management system, then the website, then a CRM, then a payment provider, each chosen to solve a specific problem. Nobody planned how they would talk to each other.

So people do the connecting: they export a file, tidy it up, import it again, retype an order, check by hand that a payment has come through. It works while volumes are low; then it becomes lost time and a source of errors, and it often raises the question of whether to keep your current tools or choose custom or off-the-shelf management software.

A practical integration example

A typical flow, purely as an illustration, for a business selling online:

1. The customer buys on the website.
2. The payment provider confirms the payment.
3. The order lands in the management system, which updates availability.
4. A request goes to the invoicing system.
5. The customer record is updated in the CRM.
6. The confirmation email goes out.

The actual order depends on your process: some businesses invoice only on dispatch, some wait for a manual check, some take deposits. That’s why an integration isn’t designed starting from the software but from the process: first you write down what should happen, then you decide which system does what.

Which systems can you connect?

In practice, almost any that offers an API or another way to exchange data:

In tourism the classic case is keeping availability aligned across website, phone and agencies: I cover it in the article on preventing overbooking across sales channels. Connecting your business data is also the foundation for an AI assistant that answers using your company data.

REST APIs, webhooks and synchronisation

These are three different things, not three interchangeable options:

• REST API: the interface. One system makes a request (“give me today’s orders”, “create this customer”) and gets a response. It’s the most common way modern software exposes its data.
• Webhook: a notification. Instead of repeatedly asking “anything new?”, the source system tells the other one when something happens, for example “payment received”. The notification usually carries a reference, and the receiver then uses the API to read the details.
• Synchronisation: the process that keeps data aligned between two systems over time, using APIs, webhooks or both.

Real-time or scheduled synchronisation

Not everything needs to be instant.

• Real-time (via webhooks or immediate calls) is for cases where a delay causes a problem: seat availability, payment confirmation, booking status.
• Scheduled (every few minutes, every night) is fine for things that can wait: price list updates, pushing data to the CRM, reports.

The right answer often combines both: the webhook brings the change straight away, and a periodic check makes sure nothing was missed. That check is called reconciliation: comparing the data in both systems and fixing any differences.

What if a system has no API?

It isn’t necessarily a dead end. Options to assess case by case:

• Automated file exports and imports (CSV, Excel, XML) to a folder or server, read and written on a schedule.
• Authorised connectors provided by the vendor or certified partners.
• Direct database access, only if the vendor allows it and with great care, because a software update can change the structure without warning.

First of all, check what your contract with the vendor allows: not everything that’s technically possible is permitted.

Security and authentication

APIs are as secure as the way they’re set up. The basics:

• Authentication: every system calling an API identifies itself with its own credentials (keys, tokens), which can be revoked individually.
• Least privilege: an integration should only be able to do what it needs. Something that reads orders shouldn’t be able to delete customers.
• Encrypted connections, and credentials stored outside the code.
• Logs: knowing who did what and when, so you can work out what happened when something goes wrong.

What happens when a system fails to respond?

Sooner or later it happens: an external service is slow, under maintenance or returns an error. A well-built integration plans for it.

• Retries: if a call fails, it’s tried again after a while, with increasing waits, instead of losing the data.
• Idempotency: if the same order arrives twice (which happens, precisely because of retries), it must be recorded only once. This is done with unique identifiers for each operation.
• Rate limits: many services cap the number of requests in a given period; the integration has to respect that and queue the rest.
• Mapping: the two systems name things differently (tax codes, order statuses, categories). The conversion rules need to be written down and maintained.
• Monitoring and alerts: when something fails for good, someone needs to know, with details of what went wrong and a way to rerun the operation.

This is the least visible part, and the one that separates a connection you can rely on from one you have to check by hand every day.

How much does API integration cost?

There’s no standard price, because it depends on factors that vary a lot between projects:

• Quality of the documentation of the systems involved: well-documented APIs need less analysis time.
• Access: some APIs are included, others need specific plans or authorisation from the vendor.
• Number of flows: syncing just orders is different from syncing orders, customers, catalogue and payments.
• Data transformation: the more differently the two systems think, the more mapping rules you need.
• Required reliability: retries, reconciliation, monitoring and alerts are extra work, but on a critical flow they’re essential.
• Maintenance: external software changes its APIs over time, and the integration has to be updated accordingly.

That’s why it almost always starts with an analysis: which systems, which data, in which direction, how urgently. It’s often worth starting with the flow that wastes the most time today and adding the others later.

When a central integration layer makes sense

With two systems, a direct connection is enough. When there are many, connecting each to every other creates a web that’s hard to maintain: any change to one system can break several links.

A central API layer is an intermediate piece of software that talks to all the others and becomes the single place for rules, logs and error handling. It also makes sense when you need to expose data to external partners. On a gaming platform I built, external operators connect through documented APIs, with separate authentication for each operator, a client library to plug into their own systems and standardised errors, so every partner always knows how to interpret a response. You can see the project among my work.

What to check before you start

• Which data you currently retype by hand, and how often.
• Which system is the source of truth for each piece of data (who wins when two values don’t match).
• Whether the software involved has documented APIs and whether your plan includes them.
• What should happen if a step fails, and who needs to know.
• Who will look after the integration when one of the systems changes.

If you’d like to work out where to start, see how I approach software integrations or tell me which tools you use and which data you copy manually, and we can assess how to connect them. The initial analysis is free.

Frequently asked questions

Can every piece of software be integrated?

Almost all of it, though not always in the same way. With a documented API the connection is more direct; otherwise automated exports or authorised connectors are options. Sometimes the limit is contractual rather than technical.

What is a webhook, in one sentence?

An automatic notice one system sends to another when something happens, so the other doesn’t have to keep asking whether anything has changed.

Does an integration need maintaining over time?

Yes. Vendors update their APIs, internal processes change and data changes. That’s why logs, alerts and documentation should be part of the project from the start.