System integration fails quietly. That's what makes it expensive.
A broken screen gets reported in minutes. A sync that stopped writing to the ERP three weeks ago gets discovered at stocktake — after twelve hundred orders reconciled wrong. We build integrations that prove they're working, not ones that only shout when they crash.
System integration is making separate software systems agree — passing orders, records, payments and events between them reliably. Canopus builds REST and GraphQL APIs, third-party connections, webhook pipelines, middleware and EDI links, with idempotency, retry handling, monitoring and scheduled reconciliation built in from the start.
The five ways an integration goes wrong
Every integration we've been called in to rescue failed in one of these ways. Each has a known engineering answer — the question is whether it was built in or left out.
Scroll the diagram sideways to see both columns.
What we connect
Named platforms, because "we integrate with anything" tells you nothing about whether we've done yours.
Payments & financial
CRM, ERP & business platforms
Logistics, mapping & communications
Identity & infrastructure
Four integration patterns, and when each is right
Picking the wrong one is how a simple integration becomes a permanent maintenance cost.
| Pattern | Use when | Avoid when | Typical latency |
|---|---|---|---|
| Synchronous API call | The user is waiting and needs the answer now — a card authorisation, a stock check at checkout | The other system is slow or unreliable; you're now as available as they are | Immediate |
| Webhook + queue | The other side pushes events — payments, shipment status, form submissions | Order matters strictly and the sender doesn't guarantee it | Seconds |
| Scheduled batch sync | High volume, no urgency — nightly catalogue, daily financial posting, EDI runs | Users expect near-real-time and will call support at 11am about it | Minutes to hours |
| Event bus / streaming | Several systems need the same event, and the list will grow | You have two systems and no plans for a third — it's overhead you'll maintain forever | Sub-second |
Scroll the table sideways for the full comparison.
The most common mistake we're called in to undo
A synchronous call to a third-party API inside the checkout path. It works in testing, and then the provider has a slow morning and your checkout starts timing out with it. Anything that isn't strictly needed to answer the user goes into a queue — the order is accepted, the downstream write happens behind it, and a failure there becomes an alert rather than a lost sale.
Building the API other people integrate with
Once a partner integrates, your response shape is a contract. Getting the discipline right early is much cheaper than a deprecation programme later.
- OpenAPI specification, generated from the codeDocumentation that can't drift from the implementation because it's produced by it.
- Explicit versioning from v1Adding a version later is harder than starting with one nobody needed yet.
- Per-client authentication and rate limitsOne partner's runaway script can't degrade everyone else's access.
- Sandbox with realistic test dataPartners integrate faster and raise fewer tickets when they can try it safely.
- Outbound webhooks with signed payloads and retriesPlus a delivery log your support team can read.
- Consistent, actionable error responsesAn error code and a message that tells the integrator what to change.
- Pagination and filtering that scaleCursor-based, so a partner pulling 400,000 records doesn't take your database with them.
- A written deprecation policyNotice period, sunset date, migration guide. Published before you need it.
How an integration project runs
Field map and system-of-record decisions
Every field that crosses the boundary, which system owns it, what happens on conflict, and what "done" looks like for each flow. This document is the integration — the code is a transcription of it.
You receive: written field map, flow diagrams, error-handling rules and a list of access we need with named owners and dates.
Contract-first development
We build against a mocked version of the other side's contract, so development isn't blocked while sandbox credentials are negotiated — the single most common source of integration delay, and rarely inside anyone's control.
You receive: working flows against mocks, plus contract tests that will run against the real sandbox nightly.
Sandbox, then production shadow
Against the real sandbox, then in production writing to a shadow table rather than the live system — so we can compare what would have been written against what the current process produces, before anything is committed.
You receive: a comparison report showing where our output differs from the current process, and why.
Cutover with monitoring already running
Dashboard, alerting on failure rate and queue depth, dead-letter queue, and a scheduled reconciliation that proves both sides agree. Monitoring is live before the integration is, not added after the first incident.
You receive: health dashboard, alert routing, runbook for the top failure modes and a daily reconciliation report.
Cost, reliability, legacy systems and EDI
How much does a system integration cost?
Three things drive it, and none of them is a feature list: how many flows cross the boundary, whether the other side publishes a documented modern API or only a database view and an SFTP drop, and how far the two systems already disagree about the same field. A legacy or on-premise endpoint costs more than two cloud products, sometimes considerably. We settle it in a paid discovery week that produces the field map, the flow diagrams and a fixed written estimate — yours to keep whether or not we build it.
Why do integrations that worked fine start failing?
Almost always one of four things: the other side deprecated an API version, a webhook was retried and processed twice, a token expired and nothing refreshed it, or the data drifted into a shape the mapping never anticipated. All four are predictable — which is why we build reconciliation and alerting rather than a script that assumes success.
What does idempotency mean for our business?
An operation can be delivered twice without happening twice. A payment webhook that times out will be retried by the sender; without an idempotency key you get a duplicate order or a double refund. We assign a unique key to every inbound event and record it, so a repeat delivery is recognised and safely ignored.
Can you integrate a legacy or on-premise system?
Yes. Where there's no API we work with what exists — a database view, a scheduled file export over SFTP, a SOAP endpoint, or a small agent alongside the system exposing a modern interface. The approach is chosen with your team, because anything touching a legacy production database needs their agreement, not just ours.
Do you build APIs for others to consume?
Yes — public and partner APIs with OpenAPI documentation, versioning, authentication, per-client rate limiting, sandbox credentials and webhook delivery with retries. The engineering that matters is versioning discipline: once a partner integrates, you can't change a response shape without a deprecation window.
How do you handle EDI?
We build EDI 850, 856, 810 and 940 handling through a value-added network or direct AS2, mapping to and from your own data model. EDI is unglamorous and specific, and the timeline usually depends on the trading partner's testing queue rather than our development — which is why we start partner certification early.
How do we know an integration is still healthy?
Every integration ships with a dashboard, alerting on failure rate and queue depth, a dead-letter queue for events that couldn't be processed, and a scheduled reconciliation proving both sides agree. Silence isn't evidence that data is flowing — a reconciliation job that finds nothing is.
Can you fix an integration someone else built?
Yes, and it's a common starting point. We audit the flows, add monitoring and reconciliation first so you can see the real failure rate, then fix in priority order. Adding visibility before changing behaviour means you can tell whether our changes helped, which is not always obvious otherwise.
Related services
Which two systems disagree, and who re-keys the difference?
That's the whole brief. Tell us the systems and the field they argue about, and an engineer replies within one business day with the pattern we'd use.
- Email — [email protected]
- Phone / WhatsApp — +91 817 979 7732
- Existing integration failing? Ask for a health audit