A CRM data contract: what to agree before integration

Before listing API methods, describe what systems exchange: an inquiry, contact, order, product or status. Identify a source of truth for each entity. If prices belong to an accounting system, editing them on the website needs agreed behaviour.

For an inquiry, define the relationship between a contact and a deal separately. One person may ask two different questions; one request may travel over the network several times. “Same phone number, discard it” confuses these cases. The process owner defines the business rule and the technical team translates it into a testable contract.

Each field needs a meaning, format, required status, owning system and a rule for an empty value. Dates need a time zone, statuses need an agreed vocabulary, and amounts need units and rounding rules. Check long text, an unusual contact and a missing optional advertising tag separately.

An illustrative example maps “selected service” on the website to a direction code in the CRM rather than an arbitrary name a manager must interpret. Do not automatically duplicate contact data or a free-form message into analytics parameters. Transfer necessary fields and agree access, retention and deletion for your project.

HTTP 200 does not always mean the entire operation succeeded. For example, official Bitrix24 documentation requires inspecting the response body; a batch can be accepted while individual commands fail. Verify the required result and its identifier for the specific integration, not just the transport status.

If the website first persists a request in a durable queue, feedback should describe acceptance rather than a completed CRM deal. If confirmation must come from the final system, agree a waiting limit and a clear failure state. Do not promise a durable queue when the implementation only uses one process’s memory.

AWS Builders’ Library describes safe retries through an intent identifier: repeating a request with the same key should not create a new side effect. That is a contract between both sides, not a universal feature of every CRM. Check whether the destination API supports it and how long it retains an outcome.

When an operation completed but its response was lost, the integration may need reconciliation through an external identifier. A phone-number hash does not replace an inquiry identifier. Process memory, a bounded cache and durable storage provide different guarantees; after restart or expiry, a retry may become a new record again. Those limits belong in the brief.

Bitrix24 publishes REST call intensity and resource-consumption limits. Cloud and self-hosted capabilities differ, and the plan and API must be checked for the actual account. Increasing parallel requests is not a universal way to speed up an integration.

Separate temporary failure, missing access, invalid data and a reached limit. Each needs a clear next action: deferred retry, field correction, access renewal or manual reconciliation. Agree who sees a stopped exchange and who may reprocess a record. Logs must not expose access credentials.

Check a valid request through to the manager’s working list, then a retry, invalid data, an unavailable system and recovery after restart. Retain identifiers and expected states without unnecessary personal data. For batch delivery, include partial success: valid records should not be endlessly recreated because one item is problematic.

The published Ru Prom case includes CRM, integration with 1C and a Telegram bot. This establishes the stated project scope, but does not disclose the API details, storage model or retry guarantees. Do not treat it as a ready-made promise for another project. An estimate needs your working system, actual statuses and permissible test data.