"Can it integrate with our existing system?" is one of the most common questions we get, and one of the hardest to answer quickly — because the honest answer depends almost entirely on what the other system allows.
What an integration actually is
Think of an API as a restaurant menu. The kitchen will make specific dishes, prepared specific ways. You cannot walk in and rearrange the kitchen — you order from what is offered.
An integration is your software placing orders from another system's menu. Everything that makes integrations easy or hard comes down to how good that menu is.
Why costs vary so widely
| The other system has… | Difficulty | Typical cost |
|---|---|---|
| Modern documented REST API | Easy | ₹40,000 – ₹1,50,000 |
| API but poor documentation | Moderate | ₹1,00,000 – ₹3,00,000 |
| Only file export/import | Awkward | ₹1,50,000 – ₹4,00,000 |
| Database access only | Risky | ₹2,00,000 – ₹6,00,000 |
| Nothing — screen scraping | Fragile | Avoid if possible |
The question that gives you a cost estimate in five minutes: ask the other vendor "do you have public API documentation, and can you send me the link?" A good link means the low end of the table. Silence or "our team can arrange something" means the high end.
One-way or two-way?
This distinction drives more cost than people expect:
One-way sync
- Data flows in a single direction
- One system is the source of truth
- No conflicts possible
- Far cheaper and more reliable
- Covers most real business needs
Two-way sync
- Both systems can change the same record
- Requires conflict resolution rules
- Needs careful loop prevention
- Substantially more expensive
- Often not actually necessary
Before paying for two-way sync, ask whether both systems genuinely need to edit the same data — or whether one could simply be the master. The answer is usually the latter, and it halves the cost.
The failure cases that must be designed for
Integrations fail routinely, and the difference between a good one and a bad one is entirely in how failure is handled:
- The other system is down Your integration must queue and retry, not lose the record silently.
- Rate limits are hit Most APIs cap requests. Bulk operations need throttling and backoff.
- Duplicate delivery Webhooks can fire twice. Every handler must be idempotent — processing the same event twice must not create two orders.
- Partial failure If three of five records sync, you need to know which two did not.
- Schema changes The other side renames a field without warning. Monitoring should catch this within hours, not at month end.
The most damaging integration bug is a silent one. An integration that stops working loudly gets fixed on day one. One that quietly drops 5% of records gets discovered during an audit months later, by which point reconciling the data is a project in itself. Insist on failure alerting as part of the scope.
Questions to ask before commissioning
- Does the other system have documented API access, and does our licence tier include it?
- Is this one-way or two-way, and which system is authoritative?
- How quickly must data move — real time, hourly, or nightly?
- What happens when the other system is unavailable?
- Who gets alerted when the integration fails?
- What is the maintenance arrangement when the other side changes their API?
When not to integrate
Integration is not always the right answer:
- Low volume. If it is ten records a week, manual entry may genuinely cost less than building and maintaining an integration.
- The other system is being replaced soon. Wait.
- An off-the-shelf connector exists. Zapier, Make, or a native connector may cover it for a small monthly fee.
- The underlying process is broken. Automating a bad process just produces bad results faster.
Need two systems talking to each other, and want an honest assessment of what it will take? Tell us which systems. See also our web application development service.