If your team types the same order into the online shop, the stock sheet and Xero, or copies every website enquiry into the CRM by hand, your systems are not integrated: your people are doing the integration. Custom software integrations connect those systems so each piece of data is entered once and moves automatically to wherever it is needed, with a record of what happened.
This guide explains system integration in plain business terms: the methods, the decisions that make an integration reliable, the security basics, when a no-code tool is enough, and what custom integration costs in pounds and dollars.
What are custom software integrations?
In short: an integration is software that moves data between two systems automatically, using an API, a webhook, a file transfer or a middleware tool.
Most businesses run five to ten systems: a CRM, an accounting package, an online shop or ERP, a help desk, e-mail and messaging, and a few spreadsheets that nobody admits are systems. Each holds part of the truth. Integration is what makes them behave like one business instead of several.
There are five common ways to connect them.
| Method | How it works | Good for | Watch out for |
|---|---|---|---|
| API (application programming interface) | One system asks another for data, or sends data to it, through a documented interface | Most modern cloud tools: CRMs, accounting, e-commerce | Rate limits, and API versions that change |
| Webhook | A system sends a message the moment something happens, such as an order being paid | Reacting within seconds | Messages can arrive twice, late or out of order |
| File or CSV exchange | One system exports a file on a schedule; the other imports it | Older systems, banks, suppliers without an API | Delays and formatting errors |
| Middleware / iPaaS (Zapier, Make, Power Automate) | Pre-built connectors you configure rather than code | Simple, low-volume flows between popular apps | Usage-based pricing, limited logic, hard to debug at scale |
| Custom integration | Code written for your systems and rules, running in your own cloud account | Complex rules, high volume, legacy systems, two-way sync | Needs an owner and occasional maintenance |
Sometimes one of your systems has no API at all, typically an older in-house database. Then part of the job is custom API development: putting a small, secure interface in front of that system that exposes only the data other systems need.
Which business systems usually need connecting?
In short: start where a person currently re-types data. That is usually sales to finance, shop to stock, and website to CRM.
A won deal becomes a customer and an invoice in Xero, QuickBooks or Sage. Payment status flows back so sales can see who has paid before promising more. This CRM integration is where many businesses start.
Orders from Shopify, WooCommerce or a marketplace reduce stock in one place, and stock levels flow back to the shop so you do not sell what you do not have. This is the most common ERP integration.
Every enquiry lands in the CRM within seconds, with its source, an owner and a follow-up task, instead of sitting in a shared inbox.
Account managers see open tickets before they call a customer. Support sees contract value and history before they reply.
Conversations are logged against the right contact, approved message templates go out from the CRM, and replies reach the person who owns the account.
The job-tracking app, the quoting spreadsheet or the warehouse scanner: small tools that become far more useful once they read and write the same records.
If you have not yet decided which system should own orders and customers, our ERP vs CRM guide sets out a working split. If you are still working out which manual processes to tackle first, start with our guide to business process automation.
Which system should be the source of truth for each field?
In short: decide, field by field, which system owns the data. Every other system reads it. This one decision prevents most integration problems.
When two systems both let staff edit a customer’s address, they will disagree within weeks, and no integration can tell which version is right. The fix is not technical. It is a short agreement about ownership.
| Data | Source of truth | Other systems |
|---|---|---|
| Leads and sales activity | CRM | Accounting never needs them |
| Billing details and VAT number | Accounting or ERP | CRM shows them read-only |
| Products and prices | ERP or the shop platform (pick one) | Everything else reads them |
| Stock levels | Stock system or ERP | The shop displays them |
| Invoices and payment status | Accounting | CRM displays them |
| Support tickets | Help desk | CRM shows a summary |
This split is illustrative. Yours depends on who edits what today. The rule does not change: one owner per field, and everyone else reads it.
One-way or two-way sync? Real time or scheduled?
In short: use one-way sync wherever you can, and real time only where a delay costs money. Two-way, real-time sync of everything is the most expensive and most fragile option.
Data flows from the owner to the readers. Simple to build, simple to test, and when something looks wrong there is only one place to fix it. Most integrations should be this.
Both systems can change the same record and push the change to the other. Sometimes necessary, for example contact details edited in both a CRM and a help desk, but it needs conflict rules: which change wins if both sides edit between syncs?
Timing is a separate decision. Real-time updates, usually triggered by webhooks, matter for new leads (a fast reply wins more of them), paid orders and stock levels (to avoid overselling). Scheduled updates, every 15 minutes or overnight, suit reporting, price lists, bank files and anything a person only looks at once a day.
Scheduled jobs are easier to check and cheaper to run. Do not pay for real time where nobody would notice the difference.
What does a well-built integration look like?
In short: it receives the event, checks it, records it, updates the other systems, and tells someone if anything fails.
Illustrative example: a UK retailer sells through Shopify, keeps stock in a custom stock system and runs its accounts in Xero. Here is the path a single order should take.
Illustrative integration: shop order to stock and accounts
- Order paid in the shopThe shop sends a webhook to the integration within seconds
- Message verified and storedThe integration checks it genuinely came from the shop and records its unique ID
- Duplicate checkIf this order ID has already been processed, stop here
- Stock reduced in the stock systemThe stock system is the source of truth for quantities
- Invoice created in XeroCustomer matched by account number or e-mail, VAT applied by the accounting rules
- Result loggedSuccess, or failure with the reason, visible on a simple status screen
- Failure? Retry, then alertAutomatic retries with growing gaps; after that, a named person is notified
Notice that the integration keeps its own log. That log is what lets you answer “did order 10452 reach Xero?” in ten seconds instead of an afternoon.
What happens when something goes wrong?
In short: integrations fail quietly unless they are designed not to. Retries, duplicate protection and monitoring separate an integration you can trust from one you have to keep checking.
Every connected system will, at some point, be slow, down for maintenance, or reject a record. Plan for it.
- Retries. If a call fails because a service is briefly unavailable, try again after a pause, and leave longer gaps each time so you do not hammer a struggling system.
- Idempotency. A technical word for a simple idea: doing something twice must have the same effect as doing it once. Shopify’s webhook documentation says the same webhook can be delivered more than once and provides an ID so duplicates can be ignored. Stripe supports idempotency keys so a request can be retried without performing the same operation twice. Without this, a retry creates a second invoice.
- Ordering. Shopify also states that it does not guarantee the order webhooks arrive in. An “order updated” message can arrive before “order created”, so the integration should check timestamps rather than assume.
- Reconciliation. Webhook delivery is not guaranteed either, and Shopify recommends reconciliation jobs as a backup. In practice: a scheduled check that compares, say, yesterday’s paid orders with yesterday’s invoices and flags any gap.
- A holding queue. Records that cannot be processed, such as an order for a product code that does not exist, are parked with the reason, so someone can fix the data and resend with one click.
- Alerts to a person. Not an e-mail to a shared inbox nobody reads. A named owner, and a message only when action is needed.
A cheap integration usually skips all of this. That is why it works in the demo and fails in month three.
How do you keep integrations secure?
In short: give each integration its own credentials with the minimum access it needs, keep secrets out of code and spreadsheets, and treat data from other systems as untrusted.
- API keys and OAuth. An API key works like a password for software. OAuth is a standard that lets you authorise an application to act on your account with limited permissions, without sharing your login, and lets you revoke that access later. Many cloud platforms support OAuth 2.0; use it where it is offered.
- Least privilege. An integration that creates invoices does not need permission to delete contacts or read payroll. Ask for the narrowest scope that works.
- Secrets stored properly. Keys belong in a secrets manager in your cloud account, never in source code, a shared document or a Zapier step anyone can open. Rotate them when a supplier or staff member leaves.
- Validate what comes in. The OWASP API Security Top 10 lists “unsafe consumption of APIs” as a risk because developers tend to trust data from third-party APIs more than user input. Its guidance is to validate and sanitise data received from integrated APIs and to use encrypted (TLS) connections for every interaction.
- Move only the fields you need. Every system that receives personal data is another system to protect. If the help desk does not need a customer’s date of birth, do not send it.
We cover access control, logging and data protection in more depth in our guide to custom business software security.
When is no-code integration enough, and when is custom worth it?
In short: Zapier, Make or Power Automate are often the right first answer. Custom integration earns its cost when volume, business rules, reliability or a missing connector make the no-code version fragile.
| Situation | No-code (Zapier, Make, Power Automate) | Custom integration |
|---|---|---|
| Popular apps, simple “when this, do that” | Usually enough | Overkill |
| Tens of records a day | Fine | Rarely needed |
| Thousands of records a day | Usage-based bill grows with volume | Hosting cost stays roughly flat |
| Complex rules, lookups, exceptions | Becomes a maze of steps nobody can follow | Written once, tested, documented |
| Legacy system with no connector | Often impossible | Custom API or file bridge |
| Duplicates, retries and reconciliation must be guaranteed | Limited control | Designed in |
| Two-way sync with conflict rules | Risky | Appropriate |
Our honest advice: if the flow is two or three steps between well-known apps at low volume, start with a no-code tool. Move to custom when the no-code flow keeps breaking, the monthly bill keeps climbing, or someone spends part of every week checking it. Our guide on when a business should build custom software applies the same test to whole systems.
How much do custom software integrations cost?
In short: DataVolve’s typical range for an automation between two systems is $800–$3,000 (£650–£2,500), usually live in 3–10 days. It is indicative and fixed in writing after scoping.
What moves the price within and beyond that range:
- API quality. Well-documented modern APIs are quick to work with. Poorly documented or legacy systems take longer, and some need a custom API first.
- Direction. Two-way sync with conflict rules costs noticeably more than one-way.
- Rules and fields. Mapping five fields is quick. Mapping fifty, with tax codes, currencies and exceptions, is not.
- Historical data. Cleaning and loading existing records, such as matching three spellings of the same customer, is often the slowest part.
- Monitoring. A status screen, reconciliation checks and alerts add a little to the build and save a lot afterwards.
Integrations that are part of a larger build, such as a custom CRM connected to accounting and the website, are priced within that project. Our typical range for a custom CRM is $10,000–$30,000 (£8,000–£24,000). Running costs are usually small: most integrations sit at the low end of typical hosting costs of about £15–£250 ($20–$300) a month. Budget for maintenance, because third-party APIs change versions and retire old ones.
Integration checklist before you build anything
In short: answer these questions first and any integration, no-code or custom, will be faster and cheaper to build.
- List every system involved and who in your business owns each one.
- Write down the data your team currently re-types, how often, and how long it takes.
- For each field, name the source of truth.
- Decide one-way or two-way for each flow, and the conflict rule if two-way.
- Decide real time or scheduled for each flow, based on what a delay actually costs.
- Check whether each system has an API or webhooks, and what plan or permissions you need to use them.
- Agree what happens on failure: how many retries, who gets the alert, and how records are fixed and resent.
- Set up credentials with the minimum access, stored in your own account.
- Plan the clean-up and loading of existing records before go-live.
- Test with real examples, including the awkward ones: refunds, duplicates, missing fields.
How DataVolve builds integrations
In short: we connect the systems you already use, in your own cloud account, with logging, retries and alerts included as standard.
Integration work is a large part of our custom software development service. We connect CRMs, accounting packages, shops, help desks, messaging and internal tools using Node.js and Python on AWS, and we often build the integrations alongside a new system as part of custom CRM development.
You own the code, the cloud account and the credentials from the first commit. You see working software in weekly demos. If a no-code tool will do the job, we will say so.
If your team is re-typing data between systems, send us two lines about the tools you use. You get a written, scoped plan within 24 hours.