Integration is a product decision, not just an API connection.
A connector can move a record. A dependable integration has to understand when the record is valid, which system owns it, what should happen on failure and how a person can recover.
What makes this transaction correct?
Define authority, identifiers, event meaning, retries and reconciliation before selecting the connector or integration platform.
Write the contract before moving the record.
- Authority
- ERP owns the order; CRM contributes account context
Conflicting fields have a defined source of truth
- Identity
- Canonical order identity + source revision
A stale update is detected before overwriting current data
- Event
- A reviewed change was authorized
A candidate extraction cannot be treated as an approved order
- Replay
- Stable request identity across retries
A repeated delivery must not create a second business action
- Completion
- Destination acknowledgment + reconciliation
Transport success alone does not establish the intended outcome
The connector does not have to be custom.
An integration platform may satisfy the contract. A bespoke service becomes worthwhile when unusual rules or stateful recovery need control the existing platform cannot provide.
Ask to replay the same event.
- An interface contract with owners
- Duplicates, stale updates, outages and credential rotation
- Reconciliation evidence and an operator recovery runbook
The complete enterprise integration argument
For CIO, VP Engineering, Business Systems
The situation behind the request
A business process spans sales, contract approval, fulfillment and billing. Systems disagree on identifiers or event timing. Staff reconcile issues because no application takes responsibility for the end-to-end transaction.
Where the obvious solution falls short
Bidirectional sync without clear ownership can create loops and lost changes. One bad retry can duplicate an order. Different security domains complicate identity and service credentials. AI cannot fix a broken integration contract.
How we would approach the work
We define system-of-record boundaries, canonical identifiers, event semantics, latency requirements, idempotency and reconciliation. Choose direct APIs, messaging, integration platforms or a bespoke integration service based on the actual problem.
What the engagement may include
- Integration map and interface contracts, owners and data lineage.
- API gateways, event/workflow orchestration where needed.
- Error handling, retries, reconciliation and human exception tools.
- Monitoring, change/compatibility tests and runbook.
The choices worth making explicitly
An existing iPaaS tool may be sufficient; avoid custom code when it adds no meaningful control or reliability. A carefully scoped bespoke service may be necessary where business rules are unusual or stateful.
What we would test before calling it ready
Test repeated events, stale updates, conflict resolution, partial outage, credentials rotation and schema changes. Measure success rates and recovery time, not merely initial throughput.
A sensible first step
Define the first transaction and its authoritative sources. A small, correct integration slice is more valuable than dozens of connectors with unclear ownership.