Contents
An API integration between CRM, accounting, and online store must do more than move fields. It must preserve the meaning of the data, avoid repeated actions, and allow a person to resolve failed exchanges. The most difficult costs to predict often appear in exceptions, recovery, and maintenance, rather than in the first successful call.
In brief
- Decide which system is the reference for each piece of data.
- Distinguish a received exchange from an actually completed operation.
- Plan for duplicates, usage limits, recoveries, and alerts.
Start with a complete business flow
Let's take a fictitious situation: an order arrives at the store, creates an opportunity in the CRM, and must generate an invoice in accounting. A connection that only creates the customer record does not complete this process. It is necessary to define what confirms the order, when the invoice can be created, and how employees see a failure.
Choose a first flow that is limited but complete. Describe its trigger, the required information, and its final state. Include a cancellation or a modification. This exercise prevents building multiple partial connections where no one fully understands the overall functioning.
development and software integration require an understanding of the current process. A market connector may cover the need; specific development may be necessary for a particular rule. The right choice depends on expected behaviors, not on the number of logos available in a catalog.
Name the reference for each piece of data
The CRM can reference the sales manager, accounting for payment terms, and the store for the initial content of an order. Document these decisions. If each system can modify the same value without a priority rule, synchronization can loop or overwrite a correction.
TableName the reference for each piece of data · shareable block
| Decision to be made | Risk without a rule | |
|---|---|---|
| Customer identity | Shared identifier and correspondence table | Multiple accounts for a single company |
| Price | Source, currency, taxes, and effective date | Invoice different from the confirmed order |
| Order status | Allowed steps and responsible system | Cancelled order still processed elsewhere |
| Payment terms | Source and modification rights | Terms replaced by an obsolete value |
| Shipping status | Source and update frequency | Customer informed of an outdated status |
Missing values also require a rule. “No phone” and “field not transmitted” do not always mean the same thing. A partial update does not necessarily have to erase information that is already present. Have these cases reviewed before choosing the exchange format.
Prevent repeated operations
A service may respond slowly even though it has already executed an operation. If the calling system retries without identifying the request, it may create two invoices or two records. Keep a stable identifier for the business operation and define how to recognize an already processed exchange.
Stripe documents an idempotency key mechanism for certain requests in its API. This is not a universal property of APIs: guarantees, durations, and covered operations must be verified for each provider. Your architecture should also consider actions that follow the call, such as a notification or a write in another tool.
Test the deliberate repetition of the same event. The expected result is a single operation or an explicit refusal, according to the contract. A success achieved only once does not demonstrate this property. Also check events that arrive out of order and concurrent modifications.
Design an understandable recovery
Classify errors: temporary unavailability, usage limit, invalid data, access denied, or unsatisfied business rule. Unavailability may justify a retry; incorrect data often requires intervention. Repeating the same error indefinitely increases costs and hides the cause.
Prepare a queue of exchanges to review with the record identifier, the step reached, the cause, and the next action. Employees do not need a complete technical log to know that an invoice has not been created. They need to know if the order can continue and who should act.
Periodic reconciliation complements events received in real-time. It compares states between systems to spot missing items. A lost event, manual intervention, or prolonged outage may produce discrepancies even when the main service has returned to normal.
Limit rights and exchanged data
Assign only the necessary accesses to each connection. An integration that reads orders does not automatically need to delete customers. Plan for credential renewal, their storage, and access revocation. Logs must not expose secrets or unnecessarily copy personal data.
OWASP notably describes the risks of authorization, excessive resource consumption, and trust in third-party APIs. In your project, translate these risks into concrete checks: rights limitations, input controls, response validation, and handling of a compromised or unavailable dependency.
Make costs visible in the submission
The budget should distinguish discovery, access to tools, data mapping, development, testing, monitoring, and maintenance. Check the required subscriptions, authorized volumes, and variable costs. A low-cost connector may require a higher software plan or significant cleanup work.
Ask what is planned when an API changes. Who monitors the provider's announcements? How is a new version tested? Who corrects a mapping rule? Maintenance is not just keeping a server running: connected systems continue to evolve.
For a custom CRM or ERP, keep the exchange rules documented and testable. The integration must remain understandable by another team. This transfer reduces dependence on a single person who alone knows the origin of a match or exception.
An illustrated flow: order, CRM, and invoice
Let's take a fictitious order COM-1042 received in a store. The store is the reference for the order; the CRM holds the business relationship; accounting holds the invoice number and status. The flow proposed below is an example architecture, to be adapted to the guarantees actually offered by the tools.
TableAn illustrated flow: order, CRM, and invoice · shareable block
| Recorded status | Scheduled recovery | |
|---|---|---|
| Receiving COM-1042 | Event received with stable identifier | A repeated event retrieves the same operation |
| Association to the CRM customer | Customer identifier and reconciliation result | An ambiguous client remains under review, with no invoice created |
| Invoice creation | External reference COM-1042 and accounting number | After the deadline has passed, check the result before recreating |
| CRM update | Link to the invoice and status of the exchange | Repeat this step alone if it fails |
| Reconciliation | Order, invoice, and CRM status reconciled | Report discrepancies to a designated manager |
Suppose accounting creates FACT-884, but the connection cuts off before returning its number. The connector does not know if the operation succeeded. Blindly retrying the creation may produce a second invoice. It must retrieve the result via a stable reference, or use an idempotence mechanism documented by the API. If none of these guarantees exist, the case goes to manual reconciliation rather than being automatically recreated.
Stripe documents this principle for its own requests; this does not prove that your accounting software offers it. You need to read the guarantees of the relevant interface, their duration, and their limitations. Storing a key in the connector alone does not make an external operation idempotent.
Four attempts to attach to the quote
- Send the same event twice: retrieve an order and an invoice, with a trace of the duplicate received.
- Cut the response after creation: retrieve the existing invoice without creating a second one.
- Temporarily block the CRM after invoicing: resume its update without retrying the invoice.
- Modify or cancel an order: apply an approved business rule; do not automatically delete an already issued invoice.
The useful log contains the order ID, the step, the date, the external identifier, and the reason for failure. It avoids copying personal data or connection secrets unnecessarily. A “retry” button must explain what it will relaunch and who can use it. The deliverable to request is therefore a flow with its states and exceptions, accompanied by proof of these attempts.
Frequently Asked Questions
Should an integration work in real time?+
Not always. A periodic update may be sufficient for a report, whereas a stock reservation requires another level of freshness. Define the acceptable delay per process and the consequences of a delay before choosing the architecture.
Why pay for development if a connector exists?+
A connector may be the right solution. However, check the fields, rules, errors, and limits it covers. Custom development should meet an identifiable need, rather than a technical preference.
How to detect incomplete synchronization?+
Track business states and failed exchanges, then periodically compare data between systems. A service availability indicator does not prove that all orders or invoices have been processed.
Can we promise there will never be duplicates?+
You need to specify the guarantees per operation and the tool limitations. Stable identifiers, idempotency mechanisms, and reconciliation checks reduce the risk. Testing should include repetitions, delays, and partial failures.
Sources and method
Stripe — Idempotent requests · OWASP — API Security Top 10, 2023 edition. Sources consulted on October 1, 2026; the grids and decision examples are an editorial analysis by Daillac.
Scope your exchanges before multiplying connectors
Introduce the systems to be connected, the data to be exchanged, and an example of an exception. We can then define the direction of the flows, the controls, and a first verifiable integration.
D
