API & systems integration
What an integration actually costs
Most of the budget goes on failure paths rather than the connection, so the honest way to size this work is by how many systems are involved and what happens when they disagree.
Get a scoped estimateWhy two quotes for the same job look nothing alike
Two firms quoting "sync our CRM to billing" can be pricing genuinely different work. One is reading records on a schedule and writing them into a table. The other is keeping two systems in agreement through outages, duplicate webhooks and a field somebody renamed on a Tuesday afternoon.
The question that moves the answer most is what happens when the two systems disagree. If nobody can name which side wins a conflict and who gets told about it, that decision arrives in the build as guesswork — and reconciliation work is where integration budgets quietly double.
Cost drivers
What actually moves the number
Feature lists are a poor predictor of integration effort. These are better, and most are knowable before anyone writes code, which is what makes the number controllable. Several of them are also reasons to build less.
How many systems, not how many features
Each system brings its own auth, rate limits and error dialect. Adding Zoho beside Salesforce is closer to a second project than a second field.
One-way read versus two-way sync
Reading records out is the easy half. Writing back forces conflict rules and deduplication, plus a decision on which side wins when a contact is edited in both.
The quality of the vendor's API
A documented, versioned API with a sandbox is a short job. An undocumented endpoint reverse-engineered from a partner's mobile app is a different order of work.
Sandbox access, or the lack of it
NetSuite and most ERPs give you a test account. Several logistics and payment partners do not, so every test writes to live data and needs cleaning up.
Historical data backfill
Connecting two systems going forward is the small half. Migrating years of existing records, with their duplicates and abandoned fields, is usually the larger one.
Duplicate delivery and replay
Webhook senders retry on timeout, so the same event arrives twice. Handling that safely is real engineering, and skipping it is how a customer gets charged twice.
Reconciliation and reporting
A scheduled job comparing both systems and reporting what disagrees. Finance asks for it the first month a number looks wrong, so it belongs in the original scope.
Compliance and data residency
PCI DSS scope, a GDPR data-processing agreement, or a client insisting card details never touch your servers. Each changes the architecture, not only the paperwork.
Rate limits and volume
A partner capping you at a few calls per second turns a simple nightly sync into a queue, a scheduler and a backpressure design.
Scope tiers
Four sizes, and what each one leaves out
Timelines assume the vendor APIs behave the way their documentation claims. When one does not, we would rather say so in discovery than in month four.
- TIER 1 — SINGLE CONNECTION
- One system, one direction. Ships in 3–4 weeks
- ₹1.5L – ₹2L$1.7k – $2.3k
- One documented vendor API, read-only, into a system you already control, with request logging and retries. Right for teams proving a workflow is worth automating at all. Does not include writing back, historical backfill, or reconciliation.
- TIER 2 — TWO-WAY SYNC
- Two systems held in agreement. Ships in 6–10 weeks
- ₹5L – ₹8L$5.7k – $9k
- Bidirectional sync with field mapping, deduplication, a named conflict-winner, idempotent webhook handling and a replayable dead-letter queue. Right for sales and finance teams re-keying the same record twice. Does not include a customer-facing API or developer portal.
- TIER 3 — INTEGRATION LAYER
- Several systems plus your own API. Ships in 3–5 months
- ₹14L – ₹24L$16k – $27k
- Multiple connectors behind one internal service, versioned REST or GraphQL endpoints documented in OpenAPI, scoped auth, rate limiting, reconciliation dashboards and alerting. Right for companies whose point-to-point integrations have started colliding. Does not include compliance certification or partner onboarding.
- TIER 4 — API AS A PRODUCT
- Self-serve API under audit. Ships in 6–12 months
- From ₹40LFrom $45k
- Developer portal, self-serve key management, usage metering, the billing hook, a partner sandbox, audit trails, and the access and residency controls a regulated review asks for. Right for firms selling API access. Does not include the audit itself or your legal counsel.
Indicative ranges for scoping conversations, not quotes. They reflect what work of this shape has cost us to deliver — your figure comes out of a paid discovery, against a written scope, and is fixed before any code is written. Gas, licences, cloud and third-party audit fees sit outside these numbers.
How we work
From a wish list to something running
Discovery is paid, and it produces the scope rather than following it. The ranges below are typical for a first release, not a promise made before we have read the vendor's documentation.
Discovery
1–2 weeksWe read the real vendor docs, test the auth and rate limits ourselves, and find the fields on either side that refuse to map cleanly.
Proof of connection
1–2 weeksOne system, one direction, against real data. If the vendor API cannot do what their sales page implied, this is where the scope shrinks or the project stops.
Build and harden
3–10 weeksThe remaining systems, the write paths, retries, the dead-letter queue and the reconciliation job, delivered in increments you review as each one lands.
Run and repair
OngoingAlert tuning, hunting quiet failures, and the rework a vendor forces when it deprecates an API version, which it will do without asking you first.
Is this worth budgeting for now?
Worth reading before you ask for a quote. The right answer is sometimes a native connector and a much smaller piece of work, and we would rather say so early.
Worth budgeting for now if…
- Someone re-keys the same record into two systems every week
- A partner has asked for an API you do not have
- The vendor publishes real documentation and gives you a sandbox account
- You can name who decides when the two systems disagree
Wait, if…
- The process you would automate is still changing every month
- Nobody has agreed which system is the source of truth
- A native connector or an off-the-shelf tool already covers it
- The volume is low enough that a spreadsheet still wins
Frequently Asked
Questions
Common questions about scoping integration work, what can safely be cut, and what it takes to keep running.
Four things, usually. The number of separate systems, because each brings its own auth, rate limits and error dialect. Whether data must flow both ways, which forces conflict rules and deduplication. The state of the vendor's API — an undocumented endpoint you reverse-engineer costs several times what a versioned one with a sandbox does. And history: connecting two systems going forward is straightforward, while migrating years of existing records, with their duplicates and abandoned fields, is the part that expands. Compliance scope sits on top of all of it wherever card or health data is involved.
Plenty. Start one-way and add the write path once you trust the read. Move from real-time to a nightly batch, which removes webhook handling entirely for most reporting use cases. Drop the admin interface and keep mappings in a config file for the first release. Connect one system rather than three. What we would not cut is idempotency, request logging and a replayable queue. Retrofitting those after a partner outage costs more than building them did, and you will have lost records in the meantime.
Historical backfill, almost every time. Then reconciliation: the scheduled job that compares both systems and reports what disagrees, which finance asks for the first month a number looks wrong. Vendor deprecations are next, since APIs change version without consulting your roadmap. Credential and token rotation needs a named owner. And somebody has to actually receive the alerts — an integration nobody watches fails quietly, and the failure is usually discovered by a customer. Sandbox access is the sleeper: with no test environment, every test writes to live data.
Running an integration is not free attention, even when nothing is broken. Expect ongoing work in four places: vendor API deprecations and forced version upgrades, credential and token rotation, alert triage when a partner has a bad day, and small mapping changes as your own data model shifts. Hosting itself is usually modest, because most integrations do very little computing. The practical answer is to budget standing engineering attention rather than treating this as a one-off, and to agree who owns the pager before launch rather than after the first quiet failure.
Phase it, in almost every case. Ship one connection, one direction, against real data, and let it run for a few weeks before adding the write path. You learn the vendor's actual rate limits and error behaviour, which no documentation describes accurately, and that knowledge reshapes the rest of the scope. The exception is a cutover migration, where two systems have to go live together or you end up maintaining both. If your point-to-point integrations are already colliding, a single shared layer beats adding another one, and that is worth doing in one pass.
Have a project in mind?
Fixed price after a paid discovery — no hourly billing. A real engineer reads every enquiry, and we reply within 24 hours.