Why SMS.ru integration with Bitrix24 breaks under load
SMS.ru integration with Bitrix24 almost always starts the same way: a couple of robots in the CRM, sending a confirmation code from a form, and notifying a manager about a new deal. At small volumes this works without complaints, so the integration is handed over as complete.
Problems begin when the same channel is used for bulk campaigns across the database, status notifications to customers, and service alerts to employees — that is, when a one-off send turns into a stream.
The first bottleneck is the absence of a message queue. Bitrix24 sends events synchronously: the robot calls an external service and waits for a response.
If the provider responds slowly or returns an error, the transaction hangs, and during bulk sending some requests simply never arrive.
The second is duplicate notifications: an event fires again when a deal stage changes, a card is updated, or a retry occurs, and the customer receives two or three identical SMS.
The third is provider limits: when the allowed sending rate is exceeded, messages are not sent, but the CRM still shows "sent," and no one notices the lost notification.
The cost of such failures is higher than it seems.
The customer does not receive the confirmation code and leaves the form, the manager learns about the request late, and a bulk campaign across the database reaches only half the recipients — while the report shows a successful send.
Let's break down how this is addressed at the architecture level: queueing, event deduplication, delivery status control, and provider error handling.
What the combination of CRM and an SMS gateway delivers
The combination is built on event exchange: a deal stage change, a new lead, a meeting reminder — the CRM generates an event, the gateway sends a message, and the delivery status is returned to the card.
The manager does not switch between windows or transfer numbers manually — the trigger fires at the moment the record changes, so the client receives a notification within a minute of the action, rather than by the end of the workday.
Delivery speed and the share of successful sends are the first metrics that show the effect. When sending through a gateway with direct connections to operators, the message goes out within seconds, and the delivery report arrives via callback and is recorded in the CRM.
If the number is unavailable or rejected by the operator, the system marks the attempt as unsuccessful and launches a retry according to a defined rule — the share of delivered messages grows without manual control from managers.
A unified message log removes the main pain point of support: all correspondence with a client — appointment confirmations, reminders, codes — sits in a single feed next to the deal history.
When handling a request, it is clear exactly what and when was sent to the client, whether it was delivered, and whether there was a reply. This eliminates disputes of "we wrote to you" and reduces the time spent clarifying circumstances.
Notification automation takes the routine off managers' hands: templates substitute the name, order number, date, and amount from the card fields, while bulk campaigns by segment are launched from the contact list. The freed-up time goes into deals, not into copying text.
Incoming reply routing is configured separately — a message from the client lands in the same channel and is not lost.
The effect can be checked across three slices: the average time from event to delivery, the share of successful sends over a period, and the number of requests closed without a manager's involvement.
These metrics are collected from the log and gateway exports, so the "before and after" comparison relies on facts, not on feelings.
Connection methods: comparison of options
There are three working schemes, and the choice between them is determined not by convenience, but by which events should go out via SMS and how critical delivery is.
The standard module is suitable for typical scenarios: a deal stage change, a task reminder, a notification to the responsible person.
A custom handler is needed where the logic depends on several entities at once — for example, an SMS goes out only when the deal amount is above a threshold and there has been no activity in recent days.
An intermediate service is justified when several systems send SMS, and the templates and send log should live in one place.
| Option | When it is suitable | Limitations |
|---|---|---|
| Standard module | Typical notifications based on CRM events, quick launch needed | Logic is limited by the settings; with non-standard conditions the process has to be adjusted to fit the module |
| Custom handler | Notifications depend on several fields, roles, and deal stages | Requires maintenance during updates; errors in conditions become visible only when a delivery failure occurs |
| Intermediate service | SMS is sent by the CRM, the website, and the accounting system; a unified log and templates are needed | An additional node appears: availability and retry control are required |
The connection limitations are common to all three schemes: a limit on message length and the cost of segments, a delay between enqueueing and actual delivery, and mandatory normalization of numbers to the international format.
Separately, it is worth considering that during bulk sends the operator may throttle the speed — this is solved by a queue with an adjustable sending rate, not by increasing the number of simultaneous requests.
In practice, a combination is most often used: the standard module covers typical notifications, while non-standard scenarios are moved to a separate handler with a shared log.
Such a hybrid provides predictable delivery without rewriting the entire notification loop every time the sales process changes.
How we conduct the SMS.ru Bitrix24 integration implementation
The integration implementation begins not with configuration, but with an analysis of where notifications already live in Bitrix24: leads, deals, invoices, tasks, reminders to managers.
At this stage, we determine which events should generally go out via SMS, and which are more logically left in the messenger or email — otherwise the client receives duplicates and unsubscribes.
Next, we build the flow scheme: which robot or business process triggers the sending, where the template is stored, what happens if the operator fails. Only after that do we connect the service and move on to checks.
- Scenario audit. We review the current rules and robots, mark trigger events and responsible parties, and remove duplicate notifications.
- Flow scheme. We agree on a map: event → condition → template → recipient → log. The client sees the logic before configuration begins.
- Connection setup. We register the sender, link it to the portal, and configure permissions and limits by direction.
- Message templates. We prepare texts for each scenario with substitution of deal and lead fields, monitoring length and readability.
- Test sending. We run each event on test entities: checking delivery, correctness of substitutions, and logging to history.
- Load testing. We observe behavior during mass mailing and when the operator is unavailable — configuring retries and administrator notification.
- Handover to operation. We finalize the regulations, train employees, and leave a log for reviewing disputed sendings.
Each step ends with approval: if at the scheme stage it turns out that a scenario is not needed, we remove it before configuration, not after launch. This way, the integration implementation does not turn into reworking a production portal.
Artifacts: what remains in your environment
After the work is completed, you are left not with "access to the contractor's personal account," but with a complete set within your own environment: configuration, templates, rules, and documentation. Below is exactly what we hand over and why each artifact is needed during operation.
- Connection configuration — parameters for integration with SMS.ru in Bitrix24: binding to the portal, access keys, sending limits, queue settings, and retry settings in case of provider failure.
- Message templates — texts for each scenario (appointment confirmation, reminder, login code, request status) with substitution variables and personalization rules based on CRM fields.
- Routing rules — the logic of which CRM or business process event triggers sending, who receives the message, in which cases it is duplicated to a backup channel, and how unsubscribes are handled.
- Sending and delivery logs — export of statuses for each message: accepted by provider, delivered, rejected, error. Needed for resolving disputed situations and reconciling with clients.
- Operation regulations — step-by-step instructions for your team: how to add a new template, change a route, check balance and reporting, and what to do in case of a mass delivery failure.
- Integration diagram — a visual map of the connections between Bitrix24, business processes, and the SMS service: where keys are stored, where logs are, what the failure points are, and how they are isolated.
- Access handover instructions — the procedure and list of permissions that are set up for your accounts so that the integration does not depend on the contractor.
Each artifact is designed so that your in-house specialist can use it without contacting us. The configuration and rules are versioned, templates are stored in an editable form, and the regulations describe typical operations and escalation points.
If you need to expand the scenarios — add a channel, change routing logic, or connect a new template — you do this independently using the documentation. Describe the task, and we will return with an estimate and a plan for handing over the materials to your environment.
Case study: a lossless notification flow
The client is a service company with a stream of requests from website forms, chats, and telephony.
Notifications about new inquiries were sent through a custom-built gateway: some messages were lost during load spikes, delivery statuses were not recorded anywhere, and operators learned about a request with a delay. Let's break down what the SMS.ru integration with Bitrix24 delivered and how the metrics changed.
What it was like before
An event from a form went into a queue, but the handler had no retries: if sending failed, the message simply disappeared. The delivered rate hovered around 82%, and queue transit time during peak hours reached 12-15 minutes.
Operators had to double-check with clients and manually duplicate notifications — over a month, several dozen support tickets piled up about "the SMS didn't arrive."
What was changed
The CRM was connected to the service through built-in business processes and robots: the event of a lead or deal being created triggers sending, and the delivery status is returned back to the record.
A queue with retries and priority separation was added — critical notifications go out first, and bulk mailings do not block them. Templates were moved into separate rules so the text could be changed without editing the logic.
Metrics after
| Metric | Before | After |
|---|---|---|
| Delivered message rate | ~82% | 98-99% |
| Queue transit time at peak | 12-15 min | up to 1 min |
| Support tickets about SMS | dozens per month | a handful |
Retries closed the class of losses during short-term failures, and status logging removed the blind spot: now you can see whether a message arrived and at which step it got stuck.
Operators stopped duplicating notifications manually — time was freed up for processing requests rather than double-checking.
How is a stock module different from a custom handler?
A stock module is a ready-made connector from the marketplace: it installs in a couple of clicks, immediately receives connection settings, and can send messages based on the events its author has provided for.
As long as the scenario is typical — application confirmation, deal status change notification, meeting reminder — it is sufficient, and we honestly tell the customer so instead of selling development where an off-the-shelf solution will do.
The limitation begins where the logic stops being typical.
A stock module does not know that a client must not be messaged outside business hours, that one segment needs one signature template and another needs a different one, or that a retry on error should follow its own schedule.
The only way around this is workarounds on top of the module, and each such workaround lives only until the next update.
We build a custom handler on the platform side: events, routing rules, templates, and the send log are ours.
The flexibility of scenarios here is complete: a condition based on time, on the assignee, on the deal amount, on the history of interactions — all of this can be configured and changed without waiting for someone else's release. An edit takes hours, not a cycle of approvals with the vendor.
The main difference shows up during platform updates. A stock module depends on how quickly its author adapts it to a new branch: after a major update, sending may stop, and you will find out about it from your clients, not from monitoring.
A custom handler relies on documented extension points, so platform updates do not break it — we verify compatibility before rollout and maintain a send log with retry delivery.
There is also a downside: a custom handler is code that needs to be maintained, tested, and documented.
That is why we make the choice based on the scenario, not on habit: if a stock module is enough, we install it and do not complicate the system; if the logic runs up against its limits, we write our own and take responsibility for how it works.
Common technical concerns
Integrating SMS.ru with Bitrix24 almost always comes down to four questions: what happens when the sending limit is exhausted, how retries are structured, where to find the message history, and how painful it is to switch providers. Below is how this is addressed at the configuration level, not through promises.
What happens when the sending limit is exhausted?
The limit is set at the service level and at the rule level in Bitrix24: daily volume, frequency per number, restrictions on bulk campaigns.
When the threshold is reached, new messages are not silently "eaten" — they are queued and sent after the counter resets, and the event is recorded in the log with the reason for rejection.
We route critical notifications (confirmation codes, request statuses) into a separate priority queue so that marketing campaigns do not block transactional ones.
How do retries work when the provider fails?
We configure retries with increasing delays: the first attempt, then a retry after a short interval, then less frequently, up to a set number of attempts.
If the provider returns a delivery error, the message is marked as undelivered and is not duplicated on the next run of the rule. Separately, we track delivery status by message ID — this shows whether the SMS reached the subscriber or got stuck on the carrier's side.
Where is the sending history stored and what does it contain?
We keep logging in Bitrix24 itself and in the integration logs: number, template, status, sending time, provider response, message ID. Using this data, any incident can be investigated — from "the client did not receive the code" to discrepancies in campaign reporting.
Logs are rotated to avoid bloating the database, but the retention depth covers the reconciliation period with the carrier.
How difficult is it to replace the SMS provider?
The sending logic is moved into a separate layer: the rules and templates in Bitrix24 remain, only the sender module and the response format of the new service change. Migration takes less time than the initial setup, because queues, retries, and logging are already described. Before switching, we run test sends to both services in parallel and compare delivery statuses.
Describe your task — we will get back to you with an estimate and a plan: which limits to set, how to configure queues, and what will go into the log.
Let's discuss your task
To make the estimate accurate rather than an "industry average," we need to understand your current sending scenario.
Describe where the events come from — deals, invoices, leads, delivery statuses — which templates are already in use, and what exactly isn't working: messages don't arrive, get duplicated, statuses get lost, or everything relies on manual sending.
That's enough for us to come back with an estimate and an implementation plan, rather than generalities.
What's worth including in the task description:
- the current scenario: where and how the message is currently generated — manually, by a robot, or by a business process;
- which events should trigger sending and under what condition — stage change, payment, assignee assignment;
- the list of templates and the variables substituted into them: number, customer name, order number, link;
- delivery requirements: whether status tracking is needed, retry on failure, sending time restrictions;
- volumes: the approximate number of messages per day and peak loads — a broadcast to the database or individual notifications;
- access and restrictions: who is responsible for the service account, whether customers have consented to messaging, whether advertising messages need to be labeled;
- reporting preferences: where to view the sending history and how to handle undelivered messages.
Based on these inputs, we'll put together a plan: which scenarios we'll automate, how we'll set up templates and retry rules, how we'll link delivery statuses to cards in Bitrix24 so the manager sees the result in a familiar interface.
We'll separately outline what we do at the launch stage and how we verify that messages are sent correctly — a test loop on real events before enabling it for the entire database.
Describe the task in free form — we'll come back with a timeline estimate and a work plan for your scenario.