n8n integration services: connect the systems your team re-keys by hand

What is an n8n integration, exactly?

An n8n integration is a workflow that watches for something happening in one system and makes the corresponding change in another, with the field mapping, validation and error handling needed to do that thousands of times without drifting. n8n is the orchestration layer; the systems stay where they are. The workflow can start from a trigger (a webhook the source system calls when a record changes), from polling (n8n asks the API every few minutes what changed since the last run), or from a schedule (a nightly job that compares both sides).

Most real integrations combine more than one of those. A quote won in the estimating tool fires a webhook that creates the job in the ERP within seconds, and a nightly reconciliation catches anything the webhook missed. Bidirectional field sync means a change on either side propagates to the other, which requires rules about which system owns which field so two updates never overwrite each other. Queues matter when one side is slow or rate-limited: n8n holds the events and drains them at the pace the target accepts instead of dropping them.

This page is about that specific outcome, your systems exchanging data reliably. If you are looking for n8n help in general, including rescuing fragile workflows or setting up self-hosting, the n8n consultant page covers the broader role.

Which integration patterns do I build with n8n?

Five patterns cover most of what mid-size companies need. Each one has a known shape, known failure modes and a known way to test it, which is why I prefer to name the pattern on the first call instead of inventing something new for every client.

AI shows up only where it pays for itself. Extracting a PO number and line items from a supplier PDF is a good use. Deciding whether an invoice should be paid is not; that stays with a person, and the workflow just puts the right information in front of them.

Which systems get connected most often?

The pairs below come up again and again in discovery calls with companies in construction, field services, logistics, distribution and professional services. They are described generically because the vendor names change and the pattern does not.

If your pair is not on the list, the questions are the same: does each side expose an API, a database or a file export, and which system owns each field. Those two answers decide the design.

What if one of your systems has no usable API?

Most mid-size stacks have at least one system that was never meant to talk to anything: a vertical ERP whose API only the vendor uses, an Access database on a shared drive, an Excel file a department has maintained for a decade. Those are the systems that make people say the integration is impossible. They are usually where the integration pays off most, and there is an order of preference for reaching them.

Whatever the method, the integration gets a monitor that alerts when the source goes quiet, because the failure mode of a CSV drop is not an error message, it is silence.

n8n Cloud or self-hosted: where should the integration run?

Both work, and I build on both. n8n Cloud means no server to run and a per-execution price; self-hosted means a Docker container and a Postgres database you control, at the cost of one more thing to keep updated. For integrations that touch an on-premise database, self-hosting is usually simpler because the instance can sit inside the same network instead of exposing the database to the internet.

My preference is fewer servers. If you already run something (a VM, a Kubernetes cluster, a Railway or cloud account), n8n goes there rather than on a new box. If you run nothing and your volume is modest, n8n Cloud is fine and I will not talk you out of it. I am not an n8n certified partner and I do not resell the subscription; the account is yours either way. When self-hosting, the deployment includes private networking to the database, secrets management, backups, monitoring and a documented upgrade path, which is the part most self-hosted installs skip.

How do you know the integration is feasible before paying for it?

Every engagement starts with a short feasibility assessment, because discovering a missing API in week two costs far more than discovering it on the first call. I talk with each department that touches the data (operations, finance, sales, IT) for twenty to thirty minutes, ask which re-keying hurts most and which fields they actually need on the other side, and check API access and credentials for each system.

The output is an integration map: one page listing each system, how it can be reached (API, database, file, email), which fields flow in which direction, which system owns each field, and where a person must approve. The fixed-price proposal is written against that map, and the map is yours whether or not you hire me for the build.

Sometimes the map shows that n8n is the wrong tool. Very high volume (hundreds of events per second), hard real-time requirements where a two-second delay matters, or a one-off data migration that runs once are better served by a small Python service, database-level replication or a script. I say that in the assessment instead of bending n8n into a shape it does not fit.

What does an n8n integration build look like end to end?

Take the most common request: estimating tool to accounting system. A quote is marked won. The estimating tool fires a webhook, or, if it has no webhooks, n8n polls its API every five minutes for quotes changed since the last run. n8n validates the payload, checks a mapping table in Postgres to see whether the customer already exists in accounting, and creates the customer if not. It then creates the job and the draft invoice with the mapped line items. If a line item has no matching product code, the workflow stops, posts the case to a Slack channel with the details, and waits.

A manager approves the draft invoice in the accounting system, the same as before, and the workflow writes the invoice number and status back to the estimating tool and the CRM. A nightly job compares won quotes against jobs and flags any gap. Every run is logged with its input and output, retries are automatic for transient errors, and secrets live in n8n credentials, never in the workflow JSON. An AI step is added only where there is unstructured input to read, for example a note field that needs to become a delivery address.

It runs on your n8n instance, in your accounts. You own the workflow JSON in your git repository, the mapping tables, the documentation and the Loom videos that walk through each workflow. If I disappear tomorrow, another engineer can pick it up from the repository in an afternoon.

What does an n8n integration cost, and who owns it afterwards?

Integrations are quoted as a single fixed price after the feasibility assessment, never hourly. The reference points are the productized systems published on this site: the AI Operating System, the closest shape to a multi-system integration, lists at USD 6,800 setup with an optional USD 1,800 per month for operation and iteration; the AI Intake Agent lists at USD 4,900 and the Lead Acquisition Engine at USD 4,000. A custom integration scope is priced against those references, in writing, before any work starts. Infrastructure and SaaS subscriptions (hosting, n8n Cloud if you choose it, LLM APIs) are billed to you directly, in your name.

A scoped build takes three weeks, three to five for larger scopes with several systems. After handoff there is a 60-day operational guarantee: if something I built breaks in that window, I fix it at no cost. Optional monthly support after that. Ownership is total: the code, the workflows, the prompts and the data are yours, the instance runs in your infrastructure, and the documentation and Looms exist so the "hit by a bus" risk is covered on both sides of the table.