API Integration & Data Synchronisation
Two systems exchange data without anyone retyping it – agreed field by field, with a rule for which side wins. Anything that cannot be transferred cleanly does not land half-finished in the target system; it lands in an error list with a reason.
The interface is rarely the hard part
Almost every system has an interface these days. And yet in many companies someone still types the same address into the CRM and a second time into the ERP. The reason is rarely technical: the two systems disagree about what a customer is. The CRM holds one address, the ERP holds a billing address and a delivery address. The shop stores the country as DE, the ERP as DEU. And a payment method called invoice in one place is called net 30 days in the other.
The real difficulty starts after that, with a question that sounds technical and is actually a business one: which system may change a field? As long as data flows one way, that is easy. As soon as both sides may write, every single field needs a rule – otherwise the nightly sync overwrites the phone number that sales corrected in the morning, and the next evening the other side writes it back. That rule is in no manual. It has to be negotiated between sales, finance and IT, and then written down – field by field, not system by system.
The third topic is the least comfortable one: what happens when it goes wrong. A route that moves several hundred records a day will fail at some point – because the target system is in a maintenance window, because a mandatory field is empty, because a vendor caps the number of calls. Fail silently and the damage outweighs the typing it replaced: nobody notices, and weeks later orders that have long since shipped are missing on the other side. That is why the visible part of our work consists of three things: the field table, the retry path, and the list of what did not get through.
Which routes are worth building
We start with the route that runs most often and has the clearest data ownership. Further objects later share the same error handling and logging.
Keep CRM and ERP in step
Customers, contacts and order status are held in both systems. Who may change which field is settled beforehand – per field, not by habit.
Connect shop and ERP
Orders in, stock levels and tracking numbers back – triggered the moment something changes instead of by a nightly full export.
Hand documents to finance
Invoices, payments and cost allocation into your accounting system, with a check before the handover rather than after it.
Connect legacy systems without an API
When all that remains is database access, a file export or an SFTP folder, we build the adapter in front of it and treat it like an API.
Events instead of nightly runs
A webhook reports the change on save; the schedule stays underneath only as a safety net in case a message goes missing.
Error route and audit trail
Every record that does not get through carries a reason, its payload and a named owner – instead of disappearing into a log file.
The field mapping, row by row
An extract from a real agreement: on the left the source field in the shop, on the right the target field in the ERP, and the rule in between. Seven fields, two of them do not pass. Below it, the path a record takes when it fails.
| Source field | Rule | Target field |
|---|---|---|
| order.orderNumberText, 12 characters | passesCopied one to one | OrderNoText, 20 characters |
| customer.emailText, unique | passesMatching key, no new record when it hits | CustomerNoNumber, from lookup |
| billingAddress.countryIsoISO-2, value DE | passesRecoded from ISO-2 to ISO-3 | CountryCodeText 3, value DEU |
| lineItem.unitPriceDecimal, gross | reviewConverted to net, rounding to two places signed off once | UnitPriceNetDecimal 10,2 |
| customer.companyText, up to 255 | reviewTruncated to 40 characters, full value kept in the log | Company1Text, 40 characters |
| customer.vatIdText, optional | conflictMandatory for business customers in the target – no value, no order | VatRegNoText, mandatory |
| order.customerCommentText, up to 2000 | excludedNo target field, deliberately not transferred | no targetstays in the shop |
Result for order 10842
- 3pass
- 2signed off once
- 1conflict
- 1no target on purpose
Seven fields, and one of them decides: without a VAT number the ERP creates no sales order. Order 10842 sits in the error list at 09:14 with its reason – not half-written into the target system.
Retry path when something fails
- Attempt 1immediately
- Attempt 2after 2 minutes
- Attempt 3after 15 minutes
- Error listnamed owner notified
Only technical failures are retried: timeouts, maintenance windows, rate limits. The missing VAT number above is a business failure – a fourth attempt will not find it either. Records like that go straight to the list.
The last two rows are the ones that matter. An integration is finished when it is settled what it does not transfer – not when the first record arrives.
Row four is the classic case: the shop calculates gross, the ERP expects net. The arithmetic is trivial, the question of how to round is a business decision. It gets made once and then sits in the table.
From the field list to a running route
-
Map fields, not systems
We do not start from shop to ERP but from field to field: which field exists on both sides, who may change it, what applies when it is empty. The result is the table above – that is the real project foundation.
-
Define trigger and sequence
Every route gets an event: a webhook on save, a schedule, or a comparison of change timestamps. Plus the rule for what happens when the same record arrives from both sides.
-
Test against real historic data
The route first runs against a copy or a test client, fed with records from the past. That is where the edge cases surface that nobody mentions in a meeting – accented characters, empty mandatory fields, duplicate customers.
-
Build the failure path before going live
Technical failures are retried to a fixed pattern; business failures go straight into a list with reason, payload and a named owner. Nothing fails silently, and nothing is written twice.
-
Switch on in stages
One direction first, then the second. New records first, then changes. The existing back catalogue is reconciled once and under control, not casually during operation.
What changes day to day
Today
- The same address is typed into two systems
- Nightly export, stale figures during the day
- Nobody knows which system is right in a conflict
- A failed import surfaces weeks later
- Any field change in the ERP breaks the export quietly
With connected systems
- The record is created once and travels on from there
- The change is in the target system seconds later
- For every field it is settled which side wins
- Whatever does not get through sits in a list with a reason
- A breakdown announces itself instead of lying idle
Where an integration is not the answer
From the outside, data synchronisation looks like a purely technical topic. We settle these four points before quoting, because they decide whether it pays off:
- At small volumes, building it does not pay. If ten records a day move between two systems, they are typed in a few minutes – and typing them needs no maintenance, no credentials and no dependency on somebody else's interface. We say so in the intro call, even when it costs the job. It gets interesting where many records move daily, or where a single mistake is expensive.
- Without an interface there is no real-time sync. Older industry software often has no API. That leaves database access, a file export or, in the worst case, a rebuilt click path through the user interface. The first two are stable; the last one breaks with every vendor update. Where only the click path remains, we advise against it.
- Data quality does not improve, it becomes visible. A sync copies duplicates, transposed digits and half-maintained addresses as well – only faster and in both directions. If you have two contradictory master data sets today, you have to decide beforehand which one counts. No software takes that decision for you, and it costs time inside your own organisation.
- Other people's systems change without you. A vendor can retire an API version, rename a field or lower a rate limit. The route then runs until the cut-off date and no further. We build in logging and alerting so it shows up immediately – but the adjustment itself is still work. Budget for maintenance, not only for the build.
Fits your systems
Scope and price
The entry price covers one route between two systems – in one direction, not both, including mapping, failure path and logging. What moves the price, we say before the quote.
- One route between two systems, live in one direction
- Field mapping as a table: source field, rule, target field, ownership
- Trigger of your choice: webhook, schedule or change timestamp
- Conversions for formats, codes, units and currencies
- Error route with retries, reason and payload
- Per-record logging and an alert when a run breaks off
- Documentation, handover session and 30 days of support
What increases the price
- Two-way sync with a priority rule per field
- More than two systems, or several data objects per route
- Systems without an API: adapters over database, file or SFTP
- One-off migration of the existing records including duplicate checks
- High volumes or tight rate limits that call for a queue
A two-way sync of several data objects across three or more systems typically sits well above that, in the region of €3,900 upwards. We quote the binding fixed price after the intro call.
All prices excl. VAT · operation and further development optionally via a support package
What you get
-
Production route
Set up from trigger to target system and signed off with real records
-
Mapping table
Every field with its rule, its owner and its behaviour on empty values – the basis for every later change
-
Error route and audit trail
Retries for technical failures, a list with reason and payload for business failures
-
Handover to your IT
Credentials, operating notes and a clear answer to what happens when a vendor changes its interface
Frequently asked questions about API integration
These solutions fit alongside
Automated Spreadsheet Data Sync
The smaller sibling: the same logic when one side is a spreadsheet rather than a system.
Automated Customer Data Updates
Capture an address change in one place and pass it on to every connected system.
E-Commerce Automation
The most common use case in detail: orders, stock and shipping between shop and warehouse.
Automated Backups & Monitoring
Monitoring for everything that has to keep running, including an alert when a route stalls.
Which data do you type twice?
In the free intro call we take one single route apart: which fields really have to travel, who is allowed to change them, and what should happen when a system does not answer. Afterwards you know whether building it pays off – or whether ten records a day are faster typed by hand.
Book a free intro callWhere API integration and data synchronisation creates value in everyday work
CRM, ERP, commerce and custom systems exchange defined data by event, with validation, logging and controlled recovery.
Three concrete operating scenarios to compare with your own process.Synchronise CRM and ERP
Customers, orders and status stay consistent through defined field and ownership rules.
Connect shop and ERP
Orders, inventory and fulfilment data move between systems based on events.
Handle failures deliberately
Invalid records enter an error route with cause, payload and a controlled retry option.
A strong fit when …
Systems provide structured data or signals and technical exceptions should escalate with logs, context and clear ownership.
- You handle recurring records using repeatable rules.
- The intake, target system and accountable business role can be named clearly.
- Exceptions are allowed to remain visible and move to people deliberately.
Deliberate automation boundary
Conflicting master data, missing required fields and unclear business mappings are never overwritten blindly.
Explore the technical approach and platformsEstimate time savings with your own volume
The calculator uses 4 minutes today and 0.5 minutes after automation as fixed example assumptions. It does not replace process analysis.
Illustrative estimate based on the visible assumptions — not a guarantee.