What is system integration? A practical guide to connecting your software

System integration is the work of connecting separate software systems so they share data and trigger each other's processes automatically. Instead of someone copying an order from the shop into the accounting package, or exporting a spreadsheet from the CRM every Monday, the systems talk to each other through APIs, events or scheduled data feeds. Done well, it removes retyping, keeps numbers consistent across the business and lets you change one system without breaking the others.

Most organisations run far more software than they have connected. MuleSoft's 2025 Connectivity Benchmark, based on a survey of more than 1,050 IT leaders, reports that the average enterprise manages 897 applications and only 29% of them are integrated. You do not need hundreds of apps to feel the problem: a business with a CRM, an online shop, an accounting tool and a warehouse system already has enough gaps for errors to creep in. This guide explains what integration involves, which patterns exist, how to choose between buying a platform and building custom code, and the reliability details that most articles skip.

What system integration actually covers

The phrase is used loosely, so it helps to separate the kinds of work it can mean. A single project often touches several of these at once.

• Data integration: keeping records consistent between systems, for example customers, products, prices or stock levels. The question is which system owns each field and how changes travel.
• Process integration: one system's action starts work in another. A paid order creates a shipment; a signed contract opens a project; a failed payment pauses a subscription.
• Presentation integration: showing information from several systems in one place, such as a customer portal that combines order history, invoices and support tickets.
• Partner (B2B) integration: exchanging data with suppliers, carriers, banks, marketplaces or government services, usually through their APIs, file drops or industry formats.
• Identity integration: single sign-on and shared user management, so people do not hold a separate login for every tool and leavers lose access everywhere at once.

Integration is different from migration. A cloud migration moves a system somewhere new; integration keeps several systems running side by side and makes them cooperate. In practice the two meet often: when you replace an old system piece by piece, integration is what keeps the old and new parts in step while both are live.

Signs your business needs integration work

• People retype the same data into two or more systems, and errors are found days later.
• Monthly reporting starts with exporting spreadsheets and reconciling them by hand.
• Different teams quote different figures for the same thing, such as revenue, stock or active customers.
• Customers see out-of-date information: an order shows as unpaid after payment, or an item shows in stock when it is not.
• Onboarding a new customer or employee means creating records in several tools one by one.
• A small automation built years ago now carries critical work, and nobody is sure how it behaves when something fails.
• You hesitate to replace a tool because too many things are wired to it in ways nobody documented.

None of these on its own justifies a large project. The test is cost and risk: how many hours a month go into manual transfer and correction, how often errors reach customers, and what a mistake costs when it happens. A ten-minute weekly export is not worth automating; a daily reconciliation that blocks invoicing usually is.

The main integration styles

The classic reference, Hohpe and Woolf's Enterprise Integration Patterns, catalogues 65 patterns, but almost every integration you will meet uses one of a handful of styles. They are not competitors so much as tools for different jobs, and a healthy estate usually mixes them.

File transfer

One system writes a file (CSV, XML, fixed-width) and another picks it up on a schedule, often over SFTP. It is old, simple and still everywhere, especially with banks, payroll providers, logistics partners and older ERPs. It works well for batch data that does not need to be current to the minute. Its weaknesses are latency, partial files, silent format changes and the absence of a clear error channel back to the sender.

Shared database

Two applications read and write the same database tables. It is fast to set up and gives everyone the same data instantly, which is why it appears in many in-house systems. It is also the style that ages worst: every application now depends on the internal structure of the database, so one schema change can break software owned by another team. Avoid it for new work unless the applications are really one system.

APIs (request and response)

One system calls another's API, usually REST or GraphQL over HTTPS, and waits for an answer. This is the default for modern SaaS products and the right choice when you need an answer now: check stock, calculate tax, create a customer. The catch is coupling in time. If the other system is slow or down, the caller has to decide what to do, and a chain of synchronous calls is only as available as its weakest link.

Messaging and events

A system publishes a message or event (order placed, invoice paid) to a queue or broker, and interested systems consume it in their own time. Senders do not need to know who listens, and a consumer that is down simply catches up later. This style suits workflows that span several systems and must survive outages. The price is more moving parts and a different way of thinking: things become consistent eventually rather than instantly, and the team has to handle duplicates and ordering.

Webhooks

A webhook is a SaaS product calling your endpoint when something happens, for example a payment provider telling you a charge succeeded. It is event-driven integration across company boundaries. Webhooks are convenient but need care: Stripe's webhook documentation, for example, warns that the same event can arrive more than once, that events are not guaranteed to arrive in the order they were generated, and that you should verify the signature and return a success response quickly before doing heavy work.

Integration architectures: point-to-point, hub, iPaaS and events

Styles describe how two systems exchange data. Architecture describes how the whole estate is wired. The arithmetic matters here: if every system talks directly to every other, five systems can need up to ten connections and ten systems up to forty-five. Each connection is code someone must maintain, monitor and update when either side changes its API.

Most mature estates end up hybrid: native connectors for simple standard flows, an iPaaS or event bus as the backbone, and custom services where the logic is specific to the business. The aim is not architectural purity but a setup where each integration has an owner, a place where failures show up, and a way to change it safely.

Buy, build or both: choosing how to integrate

Before writing any code, check the cheapest options honestly. Many SaaS products ship native integrations with each other, and an automation tool can cover low-volume, low-risk flows in an afternoon. Custom work is justified when those options cannot express your rules, cannot handle the volume, or would put a critical process on a tool nobody can test. The same reasoning applies to software generally, as covered in our guide to custom software versus off-the-shelf.

• Use a native connector when both products support each other, the connector syncs the fields you need, and you can see its sync log. Test it with real edge cases first: deleted records, merged customers, currencies, refunds.
• Use an automation tool for low-volume, non-critical flows such as posting a notification or adding a lead to a list. Keep an inventory of these, because they multiply quietly.
• Use an iPaaS when you connect many SaaS products, have a team to own the platform, and most flows are standard mappings rather than bespoke logic.
• Build a custom integration when the process is central to revenue or operations, the rules are specific to you, the volume or latency is beyond what the tools handle comfortably, or you need proper tests, code review and version control around it.
• Do not integrate at all when the data changes rarely, a manual monthly step takes minutes, or the systems are about to be replaced. Write down the manual step instead.

What makes an integration reliable

This is where most integration projects succeed or fail, and where most guides stop short. Connecting two APIs on a good day is easy. The real work is deciding what happens when a call times out halfway, a webhook arrives twice, events arrive out of order, or one system was down for six hours. These rules are worth agreeing before the build, not after the first incident.

Make every write safe to repeat

Networks fail in ambiguous ways: you send a request, the connection drops, and you do not know whether it was processed. The fix is idempotency, meaning that repeating the same operation has the same effect as doing it once. Stripe's API shows the pattern: the client sends a unique idempotency key with each create or update, and if it retries with the same key the server returns the original result instead of charging twice. Where a target API has no such feature, your integration should check for an existing record (by an external reference you store on both sides) before creating a new one.

Expect duplicates and disorder

Most queues and webhook systems deliver at least once, not exactly once. Consumers should record which event IDs they have processed and skip repeats. When order matters, for example an update must not overwrite a newer one, compare timestamps or version numbers rather than trusting arrival order, or re-fetch the current state from the source before acting.

Avoid the dual-write trap

A common bug: the application saves an order to its database and then publishes an event, and one of the two fails. Now the systems disagree with no record of why. AWS's guidance on the transactional outbox pattern describes the standard fix: write the event to an outbox table in the same database transaction as the business change, then have a separate process publish from the outbox. Change data capture from the database log is an alternative that achieves the same guarantee.

Retries, dead letters and reconciliation

• Retry temporary failures with increasing delays, and stop retrying after a limit so a broken message does not block everything behind it.
• Move messages that keep failing to a dead-letter queue with the error attached, and alert someone who can act on it.
• Respect rate limits: read the provider's headers and slow down instead of hammering the API until it blocks you.
• Run a scheduled reconciliation that compares key totals or record counts between systems and flags differences. Events get lost in ways nobody predicted; reconciliation catches what slipped through.
• Make it possible to replay a message or resync a record from an admin screen, so fixing a failure does not need a developer at a terminal.

An integration is only as good as its worst day. Design for the timeout, the duplicate and the six-hour outage first, and the happy path takes care of itself.

Observability

Every integration should log what it received, what it sent and what came back, with a correlation ID that follows a record across systems. Someone in operations, not only a developer, should be able to answer “did this order reach the warehouse?” in under a minute. Alerts belong on business signals as well as technical ones: no orders synced in the last hour on a weekday is a better alarm than CPU usage.

Data ownership and mapping: the decisions to make first

The hardest integration questions are rarely technical. They are about which system is the source of truth for each piece of data, who may change it, and what happens when two systems disagree. Writing this down before building saves weeks of rework. A simple worksheet like the one below, filled in for every shared entity, is often the most valuable document in the project.

• Identifiers: store each system's ID on the matching record in the other systems. Matching by name or email alone leads to duplicates and wrong merges.
• Reference data: agree shared lists such as countries, currencies, tax codes, units and product categories, and map values that differ between systems explicitly.
• Deletes and merges: decide what a delete means downstream. Archiving is usually safer than deleting, and merges need a rule for which record survives.
• Data quality: integration exposes existing mess. Budget time to clean duplicates and fill gaps before the first sync, or the integration will copy the problems faster.
• Backfill: plan how existing records get into the new flow, separately from the live sync, and how you check the backfill is complete.

Security and compliance in integrations

Integrations move data across trust boundaries, which makes them attractive to attackers and easy to overlook in reviews. The OWASP API Security Top 10 (2023) includes a category many teams miss, unsafe consumption of APIs: developers tend to trust data from third-party APIs more than user input, so attackers go after the integrated service instead. Treat incoming data from partners and SaaS products with the same suspicion as a public form.

• Give each integration its own credentials with the narrowest scopes it needs, never a shared admin account.
• Keep secrets in a secrets manager or the platform's encrypted settings, rotate them, and never commit them to code or paste them into automation tools you do not control.
• Verify webhook signatures and reject unsigned or stale requests.
• Validate and size-limit every payload, and protect any feature that fetches a URL supplied by another system against server-side request forgery.
• Send only the fields the other system needs. Data minimisation reduces breach impact and makes data protection assessments simpler.
• Record which personal data flows where, so you can answer access and deletion requests and keep your records of processing accurate under GDPR or similar laws.
• Keep an inventory of every integration, its owner and its credentials, and remove the ones nobody uses.

For a wider view of protecting connected systems, see our guide to cybersecurity services.

How an integration project runs, step by step

1. Inventory. List the systems involved, their owners, their APIs or export options, their limits (rate limits, sandbox availability, licence restrictions) and the integrations that already exist, official or not.
2. Map the process. Walk through the real business flow with the people who run it, including exceptions: refunds, partial shipments, cancellations, corrections, month-end.
3. Decide ownership. Fill in the data ownership worksheet and agree it with the business owners of each system.
4. Choose the pattern. For each flow, pick the style (API, event, webhook, file) and where the logic lives (connector, iPaaS, custom service).
5. Write the contract. Define payloads, field mappings, error responses and retries in a short specification. OpenAPI and AsyncAPI documents work well because both sides can test against them.
6. Build against sandboxes. Use the vendors' test environments and realistic, anonymised data. Many problems only appear with real-world data: long names, odd characters, missing fields.
7. Test failure, not only success. Simulate timeouts, duplicates, out-of-order events, expired credentials and the target being down.
8. Backfill and cut over. Load historical data, run old and new processes in parallel for a short period if the stakes are high, compare results, then switch.
9. Monitor and hand over. Set alerts, write a runbook for the common failures, and make sure the operations team knows how to check status and replay a message.

What drives the effort of an integration project

Integration estimates vary widely because the visible part, connecting two APIs, is small compared with the hidden parts: mapping, edge cases, data cleaning, failure handling and testing against systems you do not control. The main drivers are below. For a rough sense of scale on a wider project, our software cost calculator walks through the same factors.

• Number of systems and flows: each additional flow adds mapping, testing and monitoring.
• Quality of the APIs: a well-documented API with a sandbox, webhooks and idempotency support is far quicker to work with than an undocumented one, a file export or screen scraping.
• Legacy systems without APIs: you may need to build an adapter around a database, file drop or old protocol first.
• Data quality: duplicates and inconsistent reference data can take longer to fix than the integration itself.
• Volume and latency: near-real-time sync of high volumes needs queues, batching and careful rate-limit handling; a nightly batch is simpler.
• Business rules: pricing logic, tax, approvals and exceptions add design and testing time.
• Compliance: personal, health or payment data adds review, logging and access-control work.
• Access to people: waiting for credentials, sandbox access or answers from a vendor is often the longest delay on the plan.

Two illustrative shapes, to show how these factors play out. A one-way sync of paid orders from an online shop to an accounting package, using two modern APIs with webhooks, is typically the work of one senior engineer over two to four weeks, including mapping, failure handling, a backfill and monitoring. Connecting a shop, an ERP with a dated API and a third-party warehouse, with stock, orders, returns and invoices flowing both ways, is more like two engineers over two to four months, with a good share of that time spent on data mapping, reconciliation and testing with the warehouse provider. These are examples of how work is shaped, not quotes: your systems and rules decide the real number.

Common integration mistakes to avoid

• Building before agreeing ownership. Two systems that both believe they own the customer's address will overwrite each other forever.
• Testing only the happy path. The first real outage reveals duplicate invoices or missing shipments.
• Silent failure. An integration that logs errors to a file nobody reads is worse than none, because people trust it.
• Hard-coding mappings. Tax codes, warehouse IDs and price lists change; keep them in configuration someone can update.
• Coupling to internals. Reading another system's database directly, rather than its API, breaks on its next upgrade.
• No owner. Every integration needs a named person or team who receives its alerts and approves its changes.
• Forgetting the people. If the integration changes who enters what, train the teams and update their procedures, or they will keep working around it.

Integration also tends to surface deeper problems. If one of the systems is old, undocumented and hard to change, you may be better served by a plan to replace it gradually, which our legacy software modernisation guide covers, than by building ever more adapters around it.

How Authect approaches system integration

Authect is a founder-led software studio, so the person who scopes your integration is a founder who builds it, not a salesperson. Every project is led by a senior engineer. We start by mapping the business flow and the data ownership with your team, check whether a native connector or an existing platform already covers the need, and only recommend custom code where it earns its keep. When we build, we use AI-accelerated delivery with an engineer reviewing every line, and we treat failure handling, reconciliation and monitoring as part of the job rather than extras.

You own the code, the infrastructure and the documentation from day one, with no lock-in. Integration work can run as a fixed-price project when the scope is clear, as monthly sprints when it is evolving, or under a support and evolution agreement once it is live. If you are weighing up an integration, our enterprise applications and backend development pages describe the work in more detail, or you can talk to the founders directly.