CRM, ERP and APIs · 19 min
How to design CRM, ERP and API integrations that stay reliable
A practical guide to integration projects: data ownership, contracts, states, retries, failure handling, security and launch order.
Data map
An integration moves data between owners
Decide who owns each object before choosing the transport.
Integration risk
Complexity is not the number of URLs
One endpoint can be more critical than ten simple calls when money or orders depend on it.
Start with data ownership
Assign a source of truth for each object: customer, contract, order, inventory, payment or document. Two owners for one field will eventually produce conflicting states.
Draw objects and transitions, not only a list of integrations. This map is useful to business, analysts and engineers.
A data contract matters more than an endpoint name
Define fields, formats, identifiers, statuses, deletion and missing values. Ask what happens when a record arrives twice or a provider adds a field.
Provider documentation rarely covers every business limitation. Request sandbox access, real examples and an owner on the other side.
Design failure before the happy path
An external service can time out, return incomplete data or deliver events out of order. Use timeouts, bounded retries, logs and a visible “needs review” state.
Payments and orders need idempotency. A repeated notification must not create a second charge or order.
Avoid a chain of direct calls
A synchronous request that calls CRM, warehouse, payment and delivery can make every delay visible to the user. Separate critical actions from secondary updates and model intermediate states.
This does not mean every project needs a complex message bus. Choose API, events or queues from actual requirements for order, speed and recovery.
Security belongs in the contract
Document personal data, credentials, access revocation and audit requirements. Never put secrets or sensitive payloads into application logs.
Agree on API versions and backward compatibility so a provider update cannot silently break a purchase or document flow.
Launch the critical path first
Close one journey end to end: request to CRM, or order to payment and inventory reservation. Add secondary exchanges after that path is observable.
Acceptance tests should include downtime, duplicates, delays and manual recovery, not only successful responses.