ERP–CRM sync: what happens when the API fails
A flow with fictional data showing a successful sync, an API failure and the recovery of the affected record.
API, ERP and CRM integrations that hold up when something fails
Connecting two systems on a good day is easy. The hard part is what happens when the provider API returns an error, changes without notice, or the retry duplicates the record. That is what we design first.
Signs the integration is not solved
Someone copies data by hand
A person exports from one system and pastes into another. It works until they make a mistake or go on holiday.
Records duplicate
The retry creates a new record instead of completing the previous one. It surfaces weeks later, at month-end close.
Nobody knows whether the flow ran
No execution log, no failure alert: the error is discovered because a customer complains.
The provider changed the API
The integration stopped working and it is not clear who owns fixing it.
Scope
What we settle before writing code
An integration is decided by these six questions. If one has no answer, the flow will fail later.
Source, target and direction
Which system is authoritative for each field, and whether the sync is one-way or two-way. Without this there is no way to resolve a conflict.
Data and field mapping
Which fields travel, how they are transformed and what happens to the ones the target will not accept.
Authentication and permissions
Credentials, rotation, and the least privilege the integration runs with. Never under somebody's admin account.
Errors and retries
What is retried, how many times and with what backoff. And where exhausted records land, so nothing is lost.
Duplicate control
An idempotency key that is stable across both systems. It breaks more integrations than anything else and gets designed the least.
Monitoring and support
Execution logs, failure alerts and who receives them. And what happens when the provider changes the API.
What it includes and what it does not
What it includes
- Data map between systems and a system-of-record decision per field
- Flow implementation with retries, idempotency and a review queue
- Execution logging and failure alerts
- Tests covering error paths, not only the happy path
- Flow documentation and handover
What it excludes
- Licences for the connected systems and integration platforms
- Cleaning inconsistent historical data, estimated separately
- Changes to the source or target system when they do not expose what is needed
- Ongoing maintenance for API changes without a support contract
Evidence
The demo shows the failure path, not the happy one
Internal demo with fictional data: successful sync, API error and recovery of the affected record without duplicating it.
Who owns it when the provider changes the API?
It depends on whether there is a support contract. With support, we do: we monitor, detect the break and apply the change. Without support, delivery closes with documentation and handover, and a later update is quoted as new work. We put this in writing before starting.
Would a platform like n8n or Make do instead of code?
Often yes, and we say so. An automation platform handles moderate-volume flows with existing connectors well. Custom code is warranted when volume, transformation rules or audit requirements exceed what the platform supports. Technology is chosen after the scope, not before.
How long does an integration take?
A bounded integration between two systems with a documented API is measured in weeks. What stretches timelines is almost never the code: it is obtaining credentials, understanding inconsistent historical data and deciding which system is authoritative for each field.
Related services
Custom software development that connects your operation
Your own systems and platforms, when no off-the-shelf tool solves the process.
Web applications that do something, not just get read
Portals, internal applications and platforms with roles, data, security and maintenance.
Which systems need connecting?
Tell us the source, the target and what should happen when something fails. We review the case before proposing anything.