Illustrative example: an online shop sends an order to a work system. No reply arrives in time. An employee presses retry, and the manager sees two orders. The network failed once; the workload doubled.
This does not necessarily require replacing your CRM, or customer relationship management software. First examine the integration: the exchange of data between programs. “Retry” should mean continuing one operation, rather than creating another based on an employee's recollection.
A timeout does not tell you what happened
When waiting expires, the sender knows only that it did not receive a clear reply. The request may not have arrived, may have completed, or may still be processing.
Before writing again, look for the actual result using a stable identifier for the original operation. A customer name and amount are insufficient: a person can legitimately place two identical orders. Two deliveries of one request, however, should not produce two orders.
Distinguish the source order number, an individual event identifier and the version of a change. A record can change repeatedly. Treating everything with its number as a duplicate would discard legitimate updates.
What a safe retry means
The useful principle is idempotency: repeating the same action does not create a second business outcome. This is an integration implementation requirement, not a universal Bitrix24 switch.
Ask the implementer where the operation key is stored, how the outcome is recorded and what happens if identical requests arrive simultaneously. A simple “search, then create” sequence may be insufficient: two workers can both find nothing before either creates the record.
For creation, preserve the link between the source order and the resulting record. For updates, agree how to distinguish fresh information from a delayed version. A retry must not roll a confirmed state backwards.
Queues need rules too
Official Bitrix24 documentation recommends durably saving an incoming event before returning success and processing heavy work separately. It also states that a regular Bitrix24 event is not resent when the handler returns an error. Do not base recovery on “the platform will send it again”.
Your integration's own queue can nevertheless repeat processing after a failure. This is where preventing a second outcome matters. Define attempt limits, delays, permanent error handling and notification of the responsible person in advance.
Do not endlessly repeat a request containing invalid data or lacking permission. Fix the cause, check the state and then decide which operation to resume.
Test three awkward moments
- The recipient saved the order but the reply was lost: retry finds the existing result.
- Two workers receive the same operation simultaneously: only one order appears.
- An older change arrives after a newer one: current data is not overwritten.
Use training records and agree safe test conditions. Logs should identify the operation, time, attempt and result without exposing passwords, tokens or unnecessary customer information.
Discuss the change concretely
If one side is Bitrix24, check REST API availability—the programmatic exchange interface—and permissions for your portal. Check the other program separately. Having two APIs alone does not prevent duplicates.
For a business in Kazakhstan, start with one reproducible case: the source operation, its identifier and the actual outcome in both systems. The QQDev REST API development page is a place to discuss retry rules and logging for your exchange. You do not need to decide on replacing a working system for one button.