Most businesses run on several systems that do not talk to each other. Your accounting package holds invoices. Your CRM holds customers. Your website takes orders. Someone copies data from one into another by hand, and the copy is late or wrong.
An integration is the software that makes those systems share data on their own. This article explains what an API is, what an integration involves, what drives the cost, and why estimates for this kind of work miss more often than for a fresh app.
What an API is
An API (application programming interface) is a set of rules a piece of software publishes so that other software can talk to it. Instead of a screen for a person, it offers a door for a program. One program asks for a customer's orders, or tells the other to create an invoice, and the answer comes back in a structured format a machine can read.
Most modern systems have one. Accounting tools, payment processors, shipping carriers, CRMs and marketing platforms all publish APIs. Some are good: clear documentation, stable behaviour, a test environment. Some are thin, poorly documented, or change without notice. The quality of the API on the other side is the single biggest factor in how long the work takes, and you do not control it.
What an integration is
An integration is the code that sits between two or more systems and uses their APIs to move data. It has a few parts:
- A trigger: an event, such as a new order, or a schedule, such as every hour
- A mapping: field X in system A becomes field Y in system B, with formats, units and codes converted
- Error handling: what happens when a system is down, rejects a record, or returns something unexpected
- Logging and alerts: so you know what moved, what did not, and why
The mapping sounds like the hard part. It usually is not. Error handling is where most of the work lives, and it is the part most people leave out of the budget.
Where compliance fits
Some integrations exist because a rule says so. Tax reporting, payroll filings, financial records and identity checks all come with rules about what data must move, where, in what format, and what record you must keep of it. We build compliance software for this: the integration plus the audit trail and controls the rule requires. The mechanism is the same as any other integration. The difference is that failure carries a legal cost, so the logging and error handling must be stronger, and that shows in the estimate.
What drives the cost
When we scope an integration, a few things matter more than anything else.
- How many systems, and how many directions. One way from A to B is simplest. Two-way sync, where either side can change a record, roughly doubles the logic and adds rules for conflicts.
- The quality of each API. A documented API with a sandbox is quick to work with. One with no test environment, tight rate limits or odd behaviour costs time in discovery before any real code is written.
- Volume and timing. A few records a day is a different problem from thousands a minute. Real time is harder than a nightly batch.
- How clean the data is. If two systems hold the same customer under different names and addresses, someone has to decide which is right, and code has to enforce that decision.
- What should happen on failure. Retry, skip, hold for review, or stop everything. Each answer is a different amount of work.
Why estimates go wrong
Integration estimates miss for specific reasons.
The other system is not under your control. With a fresh app, the behaviour is set by your own code. An integration depends on software someone else built, and you only learn how it really behaves by using it. Documentation describes what the API is meant to do. The real thing differs in small ways, and each difference costs time.
Edge cases hide in old data. The first hundred records go through. Record one hundred and one has a date in a format nobody expected, or a field that was quietly repurposed years ago.
Nobody owns the business rules. When two systems disagree, which one wins? If no one can answer, the developer guesses, and the guess is wrong, and it gets found in production.
Testing is harder. You cannot casually test against a live accounting system. If there is no sandbox, you build a stand-in, or you test very carefully against the real thing.
How to get a better estimate
- List every system involved, and whether each has a documented API and a test environment
- Pull a sample of real data, including old records, not just recent clean ones
- Decide which system is the source of truth for customers, products, orders and payments
- Write down the failure cases and who should be told
- Start with one direction and one type of record, then add the rest
Getting a number
Our estimator gives a price range in minutes from the current rate card. It shows build cost, monthly costs, effort by role, a timeline, and every assumption behind the number. The assumptions matter most for integrations, because that is where the risk sits. Read them and tell us which ones are wrong.
Monthly costs matter here too. An integration is never quite finished. APIs change, systems get upgraded, and data drifts. A fixed price works when the systems and scope are known. A monthly block of hours, with a promised response time, works for keeping the integration running once it is live. We do both, and we are open for projects now.
