Integration of SMS service SMSC with Bitrix24

SMSC Service Integration with Bitrix24

SMSC.ru is one of the oldest SMS aggregators in Russia. It has two features that distinguish it from competitors: HLR requests to check number activity and cascading SMS → Viber sending (or vice versa) within a single API call. When integrated with Bitrix24, these capabilities are translated into CRM: managers send messages from a deal card, robots send notifications automatically, and SMSC automatically selects the optimal delivery channel.

Provider Registration in Bitrix24

Like any external SMS service, SMSC is connected through the messageservice module. The provider is registered via REST method:

messageservice.sender.add({
  CODE: "smsc",
  TYPE: "SMS",
  HANDLER: "https://your-domain.com/handler/smsc.php"
})

The handler (HANDLER) receives from Bitrix24 the recipient number, message text, and internal identifier. Then it forms a request to the SMSC API:

https://smsc.ru/sys/send.php?login=LOGIN&psw=PASSWORD&phones=NUMBER&mes=TEXT&fmt=3&op=1

Parameter fmt=3 — response in JSON. Parameter op=1 — request delivery status in response (SMSC returns id of the message and cnt — number of SMS segments).

The handler saves the mapping message_id (Bitrix24) → id (SMSC) and returns confirmation to Bitrix24.

HLR Requests: Verifying Numbers Before Broadcast

HLR (Home Location Register) — a request to the telecom operator that checks if a number is active, which network the subscriber is on, and whether they can receive SMS. SMSC provides HLR through a separate API method:

https://smsc.ru/sys/hlr.php?login=LOGIN&psw=PASSWORD&phones=NUMBER&fmt=3

The response contains:

• status — number status (0 = active, 1 = unavailable, 2 = doesn't exist)
• operator — current telecom operator
• region — number registration region

Why this matters in Bitrix24 context:

• Before a mass broadcast via CRM marketing, run the contact base through HLR. Remove unavailable and non-existent numbers — save budget and reduce error rate.
• When creating a lead from an incoming call, you can automatically determine the operator and region via a business process with HTTP request to SMSC HLR. The result is recorded in custom fields UF_CRM_OPERATOR and UF_CRM_REGION.

In practice, an HLR request costs 0.2–0.5 rubles per number. With a base of 10,000 contacts, verification costs 2,000–5,000 rubles, but saves significantly more by excluding invalid numbers from broadcasts.

Cascading Send: SMS + Viber

SMSC supports cascading delivery within a single API call. The logic:

1. Message is sent via Viber.
2. If the subscriber doesn't read it within a specified time (usually 1–2 hours) — SMS is automatically sent.

API parameters:

https://smsc.ru/sys/send.php?login=LOGIN&psw=PASSWORD&phones=NUMBER&mes=TEXT&fmt=3&viber=1&viber_timeout=3600

viber=1 — attempt delivery via Viber. viber_timeout=3600 — timeout in seconds before fallback to SMS.

Viber message cost is usually lower than SMS (1.5–2 times for Russian numbers). Cascade enables delivery to the maximum number of recipients at minimum cost: those with Viber receive a cheaper message, others receive SMS.

In Bitrix24, cascade is configured at the handler level. The CRM robot calls the standard "Send SMS" action, and your handler decides — send via Viber with fallback or pure SMS — depending on message type, segment, or settings.

Batch Sending

SMSC accepts up to 100 numbers in one request (comma-separated in the phones parameter). For mass broadcasts via CRM marketing Bitrix24, this is critical: instead of 10,000 separate requests, the handler groups numbers into batches of 100 and sends 100 requests.

Benefit: broadcast speed increases by an order of magnitude, load on your server and SMSC API is minimal.

Implementation: the handler receives requests from Bitrix24 (each — one number), puts them in a queue (Redis, database, file), a cron task every 5–10 seconds takes up to 100 numbers from the queue and sends them in a batch. Statuses are mapped back by each message's id.

Callback for Delivery Statuses

SMSC sends status notifications to the specified URL. Configuration — in the SMSC personal account (section "Settings → Status Handler"):

• 1 — delivered
• 2 — not delivered (error)
• 3 — not delivered (expired)
• 20 — delivered via Viber
• 22 — not delivered via Viber, SMS sent (cascade)

The handler receives id and status, finds the associated Bitrix24 message_id, updates the status in CRM.

Status "22" is especially useful: it shows that cascade worked and the client received SMS instead of Viber. This information can be recorded in a custom field of the contact — on the next broadcast, send SMS directly, skipping Viber timeout.

Implementation Timeline

What We Configure

• SMSC registration as provider via messageservice.sender.add
• Handler for Bitrix24 requests → SMSC API with cascade SMS/Viber support
• Batch sending with queue and grouping up to 100 numbers
• HLR verification of contact base before broadcast
• Callback handler for delivery statuses (including cascade statuses)
• CRM robots for transactional notifications
• Mass broadcasts via CRM marketing
• Custom fields: telecom operator, region, preferred channel
• Testing: send SMS, send via Viber, cascade, batch broadcast, HLR verification