A CRM and an ERP rarely mean the same thing by “customer.” The CRM may own the relationship and sales pipeline; the ERP may own billing identity, tax details, credit limits and invoices. A single API layer helps when it makes those ownership rules explicit. A gateway alone does not solve inconsistent data.
Decide which system owns each field
Write a field map before writing code. For every identifier, name, address, tax number, payment term and status, record the owner, allowed editors, validation rule and conflict rule. Give each customer a stable cross-system ID. Do not assume that matching on company name or email will remain reliable after a rename, merger or duplicate import.
Example: a salesperson changes the trading name in the CRM. The integration can update the ERP display name, but it should not silently overwrite a verified legal name or tax registration. That difference belongs in the contract of the API, not in an exception buried in a script.
Use a narrow domain API
Expose operations such as createCustomerDraft, approveBillingIdentity, syncContact and getInvoiceStatus. Avoid exposing every ERP table and every CRM object through a generic proxy. The API layer should translate each system's payload into a stable domain model, validate it, apply authorisation, and record the outcome. Keep adapters for the CRM and ERP behind that contract so either vendor can change without forcing every caller to change.
For writes, choose whether the call is synchronous or queued. A queued integration can return a tracking ID while the ERP processes the change. The caller can then check pending, applied or failed rather than assuming a successful HTTP response means the ERP record exists.
Design for retries and conflicts
Networks fail. Webhooks can arrive twice or out of order. Give every business event an immutable ID and every write an idempotency key. Store the last accepted version from each system. If the same event arrives again, return the prior result; if an older version arrives, reject or quarantine it. Do not use “last write wins” for credit limits, bank details or legal identity.
Keep a dead-letter queue with a named owner. Log the source record ID, destination record ID, operation, timestamp, validation errors and retry count, while limiting sensitive data in logs. Build a reconciliation report that compares important fields across both systems daily. Monitoring only API uptime will miss semantic failures such as a customer mapped to the wrong account.
Roll out one object at a time
Start with one direction and one object, such as approved CRM opportunities becoming ERP sales-order drafts. Test duplicates, updates, deletions, missing tax data, permission failures and ERP downtime using synthetic records. Then add the reverse flow for invoice status. Measure successful sync rate, exception age, manual corrections and time saved. These are more useful than a diagram showing two connected logos.
Microsoft's API design guidance recommends domain-oriented contracts and explicit idempotency for side-effecting operations. Those principles apply whether the integration runs on Azure, another cloud or a private network.
I work at OneBonsAI Gulf. Our system integration service covers scoping the ownership, APIs and operational controls around existing business systems.
Further reading: Microsoft Azure Architecture Center: API design.
Top comments (0)