Every business runs on several systems: a website, a CRM, accounting, email, a calendar, maybe a shop, a booking tool or a stock system. An integration is simply the arrangement that lets data move between two of them automatically, so that nobody has to copy it. The technical means is usually an API, the interface each system offers for other software to read and write its data.
That is the whole idea. The interesting part is choosing which integrations to build, and how.
The integrations most businesses need first
- Website enquiry to CRM. A form submission creates a lead with the right source and owner, instead of an email someone has to retype.
- Orders to accounting. Online orders become invoices or sales records automatically, with payments matched.
- Bookings to calendar and reminders. A booking on the site appears in the team's calendar and triggers a confirmation by email or WhatsApp.
- Payments. A payment provider connected so the site knows what has been paid and the books know too.
- Stock and prices. Product availability and prices on the site follow the stock system, not a weekly manual update.
- Newsletter and marketing lists. Sign-ups and customers flow into the mailing tool with the consent recorded.
Each removes a manual step that is done many times a day, which is where the value is.
Automation platform or custom code?
Platforms such as Zapier, Make and n8n let you connect common tools without programming: when this happens in system A, do that in system B. They are the right choice when:
- both systems are popular and well supported on the platform,
- the logic is simple ("new form entry, create contact"),
- volume is modest, and
- you are happy to pay a monthly fee per workflow.
Custom code is the better choice when:
- one of the systems is unusual, in-house or has a poor connector,
- the logic has rules ("only if the order is over this amount and the customer is new, then..."),
- volume is high enough that per-task pricing becomes expensive,
- the integration must be reliable under failure, with retries and alerts, or
- data must not pass through a third-party platform for privacy or contractual reasons.
Many businesses use both: a platform for the simple links, custom code for the one or two that matter most.
What to decide before anything is connected
- Which system is the source of truth for each kind of data? If a customer's address changes, where is it changed, and which direction does it flow? Two-way sync is far harder than one-way; avoid it unless you truly need it.
- What happens when it fails? Systems go down and APIs change. A good integration retries, logs what it did, and tells someone when it gives up. Decide who that someone is.
- Which data crosses which boundary? Customer data moving to a new provider, possibly in another country, is a privacy question. Check what your privacy notice says and whether the provider's terms fit.
- Who holds the keys? API credentials should belong to the business, be stored securely, and be revocable when a provider or developer changes. They should never be in a spreadsheet.
- What are the limits? Most APIs cap how many requests you can make. A nightly sync of ten thousand products is a different design from a real-time update of one.
Start with one
The best first integration is the one that removes the most tedious daily task, has clear rules and involves two systems with decent APIs. Build that, run it for a few weeks, and you will understand your own data flows far better before tackling the next. Trying to connect everything at once is how integration projects stall.
Maintenance is part of the deal
APIs change versions, keys expire, a provider gets acquired and renames things. An integration needs someone to watch its logs and update it occasionally. Build that into the arrangement from the start, whether it is you, your developer or a platform's support.
If you can name the two tools and say what should flow between them, we can usually outline the simplest reliable way to connect them in a short conversation. That is a good place to start.