System integrations: connecting the tools you already use

A system integration is the connection that moves data between the tools your company already runs, such as your shop, CRM, accounting software, email and spreadsheets, so that nobody has to copy it by hand. It is for companies that have outgrown re-typing and forwarding but do not want to replace the systems that work.

Key takeaways

• Integration is about data moving reliably between the systems you keep, not about buying a new system.
• APIs let systems be asked for data; webhooks let systems announce changes. Most integrations use both.
• A workflow tool such as n8n covers many cases. Custom code is for high volume, complex logic, or where no connector exists.
• The data stays yours: your accounts, your databases, your exports. Insist on it in every contract.
• EU hosting and clear GDPR processing roles are decisions to make before the first connection, not after.
• Every integration fails sometimes. Monitoring, retries and a person who is notified are part of the build.

The three mechanisms

APIs. An application programming interface is the way one system lets another read or write its data in a structured form. Your shop has an API that can list today's orders; your accounting system has one that can create an invoice. An integration calls the first, transforms the result and calls the second.

Webhooks. Instead of asking a system every few minutes whether anything changed, a webhook lets the system send a message the moment something happens: a new order, a paid invoice, a form submission. Webhooks make integrations immediate and reduce needless traffic.

Workflow tools. Products such as n8n provide a visual canvas where steps are connected: receive a webhook, look up a customer, branch on a field, write to a sheet, send a message. They ship with connectors for common systems and can be self-hosted (https://docs.n8n.io/hosting/), which matters for where your data is processed.

When a workflow tool is enough

A workflow tool fits when:

• The systems involved have ready connectors or clean APIs.
• The volume is moderate: hundreds or a few thousand events a day, not millions.
• The logic is a sequence of steps with a few branches, not a long algorithm.
• The people who will adjust the flow later are not developers but need to see what it does.

For many small and medium-sized companies, this covers most of the first year of automation: lead routing, order notifications, invoice hand-offs, report assembly, social media publishing.

When custom code is needed

Custom code earns its place when:

• A system has no API or connector and data has to be extracted from files, portals or email attachments.
• Transformations are complex: matching products across catalogs, reconciling payments, applying pricing rules.
• Volume or response-time requirements exceed what a workflow runner handles comfortably.
• The integration is part of a product you sell, where tests, versioning and deployment have to be strict.

The two approaches combine well. A common pattern is a workflow tool for orchestration and small custom services for the hard steps. Deciding where the line falls is a design task, and it should be revisited as the volume grows.

Data ownership

Integrations touch your most valuable data: customers, orders, invoices. Three rules keep it yours.

1. Accounts and credentials belong to the company, not to the agency. API keys, hosting, domains and the workflow instance are created in your name, and the people who built them hold administrator access that you can remove.
2. Data lives in systems you can export from. If an integration keeps its own database, you have a documented way to get everything out.
3. Logic is documented in plain language. For each flow: what triggers it, what it reads, what it writes, and who is notified when it fails. A diagram and one page of text are enough.

EU hosting and GDPR roles

Most integration data is personal data under the GDPR, Regulation (EU) 2016/679 (https://eur-lex.europa.eu/eli/reg/2016/679/oj). Two decisions follow.

Where the data is processed. Running the workflow runner and any databases on servers in the EU avoids the questions that come with transfers to third countries (Chapter V of the Regulation). Many connected services are themselves operated outside the EU; for those, check the provider's terms and the transfer mechanism they rely on.

Who is controller and who is processor. Your company decides why and how customer data is processed; it is the controller (Article 4(7)). An agency that builds and operates an integration on your behalf, and any service that processes the data for you, acts as a processor (Article 4(8)) and needs a written data processing agreement under Article 28. This is standard paperwork. The point is to have it in place before live data flows, and to include the integration in your records of processing activities (Article 30).

AI steps in a flow, for example a model that reads an email and classifies it, are also processing. The provider of that model is a processor too, and their terms should state what they do with the data sent to them.

Monitoring and failure handling

An integration that works silently for months will fail one day: an API changes, a token expires, a field is renamed, a service is down. Design for it.

• Retries for temporary failures, with a limit, so a short outage does not lose events.
• A holding queue where failed events wait to be reprocessed instead of disappearing.
• Alerts to a person, by email or chat, when a flow fails more than a set number of times or has not run when expected.
• Logs that show, for each event, what came in and what went out, kept long enough to investigate.
• A monthly check of tokens, connector versions and volume.

Failure handling is also where people fit. A flow that cannot decide, for example an invoice that matches no supplier, should create a task for a person rather than guess.

Keeping the team in control

The companies that get lasting value from integrations are the ones whose own people can see and adjust them. Practical steps: give the operations lead access to the workflow canvas, keep a list of running flows with their owners, agree who approves a change, and run every new flow alongside the manual process until it has proven itself.

How we do it at Hot Skulls Labs

We start every integration with discovery: we walk through the process with the people who run it and write down each system, each step and each decision. From that, we draw the flows and mark which steps are plain data movement and which need judgment.

Our default pattern is the same one we use in all our automation work: a trigger (a webhook or a schedule), an AI step where judgment is needed (classification, extraction, drafting), a human approval step for anything that acts outward or changes financial records, and execution into the target systems. Plain integrations skip the AI step; sensitive ones never skip the approval.

We pilot one flow first and run it beside the manual process. We build with n8n where connectors and volume allow it, and write custom services in code where they do not; often the two run together. We host on EU servers, create all accounts in the client's name, sign a data processing agreement before live data flows, and hand over documentation that names each flow, its trigger, its owner and its alert.

Operation is part of the work. We monitor the flows, review the exceptions with the client, and adjust as systems and the business change. These patterns were first built and run in Strady, our own product, before we offered them to clients.