A manager opens a lead card in Bitrix24 and wants to know who they are dealing with: how many certificates and declarations the counterparty holds, under which technical regulations, and the trend. They will not go to a separate analytics system for this. If the switch takes more than 10 seconds, the sale goes ahead without context. We embedded the analytics straight into the Lead, Deal, and Company cards. The key decision came at the start: an embed in someone else’s portal breaks on any major Bitrix update, so the embed itself holds no logic, and all search and aggregation live on our server. Real life tested the design twice. When an outside administrator wiped the integration by accident, we had the widget back in about 20 minutes. When Bitrix changed how it returned data and the widget went down across every instance at once, we fixed it the same day.
Snapshot
| Industry | Product certification, B2B market analytics |
| End client | Certificate Analytics |
| Engagement | Ongoing support: a series of specs for Bitrix24 widgets and apps |
| Project type | A widget in CRM cards that shows certification analytics for a counterparty, plus the server search service under it |
| Work done | Widget in Leads, Deals and Companies; a second widget version with caching and monitoring; a task-assignment module; rollout to several Bitrix24 instances |
| Project dates | Widget in amoCRM in 2022, port to Bitrix24 from late 2024, continuing |
| Effort | over 143 hours of confirmed estimates (133 h widget v1 + 10 h assignment module; v2 scope not quantified in hours) |
| Team | Anton Hersun (project lead; built widget v1 himself), then a widget-and-parser developer took over the track and runs v2 onward |
| Tech stack | Bitrix24 REST API · embedding in CRM cards · Laravel backend · search across six registries via ClickHouse · several instances |
| Delivered | Widget in three CRM sections across several instances, a second widget version, a task-assignment module. Status exchange with 1C stayed at proposal stage; the “Price” product was halted on the client’s side |
The problem
The client lives in Bitrix24 as its main CRM tool: leads, deals, companies. Every counterparty company card holds an OGRN, BIN, or INN field, and from that identifier the internal analytics platform pulls the data: how many certificates and declarations the company holds, across which registries, and the trend. The manager needs all of that inside Bitrix24, not in a separate window.
The widget’s history started before Bitrix. In 2022 we built the same widget for amoCRM: documents by INN/OGRN right in the card, plus a subscription to new-document notifications. When the client decided in 2023 to move off amoCRM to Bitrix24, the amoCRM widget was switched off, and the port to the new portal came as a separate spec.
After that the tasks arrived in stages:
- October 2023: a concept for a Bitrix24 CRM app (estimate 160–220 h), the start slipped several times and folded into a narrower widget
- November 2024: spec for the widget in Leads, Deals and Companies (133 h)
- November 2024: a proposal to exchange document statuses with 1C, which the client chose to defer
- August–September 2025: a second widget version, the “big spec”
- September 2025: a task-assignment module (10 h)
- Spring 2026: a “Price System” product proposal for Bitrix24, halted by the client’s partners
Before widget v1 started, the client passed on a condition from their partners: begin at 50% prepayment, the rest after delivery. We agreed without argument. Prepayment arrived on 26 December 2024, and development was planned for January.
Why this is hard. The embed lives in someone else’s portal, which updates without your knowledge, and the client runs several such portals. A widget in a lead card breaks on any major Bitrix or REST API update. That happened twice: once an outside portal administrator wiped the whole integration by accident, and once the widget stopped working across every instance at once after a change on Bitrix’s side. Had we kept business logic inside the embed, each such event would have meant days of managers sitting idle. So we split the architecture into two layers from the start: a thin embed responsible only for showing the page, with all search and aggregation logic running on our server.
How we did it
1. The backend is ours, the widget is a thin embed.
The Bitrix24 widget receives information about the open card, takes the OGRN field value, and sends a request to our Laravel service. Search across the registries, aggregation, building the output: all of it lives on the Laravel side, and the widget shows a finished page. If Bitrix24 changes its embed API, only the thin embed needs reworking, not the service.
2. One service for three CRM sections.
In the main spec (133 h) the widget embeds in three places in the portal: the Lead, Deal, and Company card. The counterparty identifier comes from a different source each time: from the Company card directly, from the Deal via the linked company, and from the Lead via its own field (leads have their own, and a lead must be tied to a company). The service does not care where the identifier came from: the output is the same analytics page. Instead of three separate widgets, we got one service.
3. Search across six registries via ClickHouse: 300 ms per query.
For one OGRN the widget searches six tables at once: RF certificates and declarations, Kyrgyzstan certificates and declarations, the Kazakhstan registry, and the Belarus registry. On a regular database, with volumes grown, that search ran for seconds. We plugged in ClickHouse, and the search settled into the 300 ms to 1 second range even on the heaviest Russian registry. Building the output adds another couple of seconds. A hundred managers can search at once without lag. For a storage failure we added a switch: if ClickHouse is down, the widget falls back instantly to the regular database and keeps working.
4. Task assignment: counting new documents and notifications.
A manager can subscribe a counterparty card to tracking. Every 2 hours the system recounts new documents for the subscribed INNs, and every 2.5 hours it creates “tasks,” notification items, in the matching leads, deals, and companies. That way a manager learns about a counterparty’s new certificate without opening the card on purpose.
5. The second version as a rethink, not a patch (the “big spec”).
By v2 so many subscriptions had piled up that the old mechanism could no longer keep pace: 13 thousand INNs under tracking would not finish processing inside the allotted 2 hours, and task assignment silently dropped out. First we stretched the interval temporarily, then sat down for a full review. The “big spec” covered fixing task assignment under the grown load, supporting several OGRNs in one entity, archiving subscriptions of departed employees, caching (the card does not hit the database again if the data has not changed), and a separate OGRN-processing monitor. We did not even try to squeeze all that into a minor update: tasks like these always come out three times more expensive in hours. Caching landed overnight by 25 September 2025.
6. The task-assignment module as a separate spec (10 h).
A question came up: who should a notification task go to, the entity’s owner or the employee who subscribed the card? And what to do if there is no owner or the system will not let one be assigned. The logic of “assign to the owner, fall back to the user, on the fly” went into a separate 10-hour module, so it could live independently of the widget core and be configured both in the box and in the widget itself. We shipped it on 29 September 2025 and added statistics in the monitor on top.
Results
| Metric | Value |
|---|---|
| Confirmed estimates | over 143 hours (133 h v1 + 10 h assignment module) |
| Embedding points in Bitrix24 | 3 (Leads, Deals, Companies) |
| Registries in one search | 6 (RF cert/decl, KG cert/decl, KZ, Belarus) |
| Search speed after ClickHouse | 300 ms to 1 second instead of several seconds |
| Widget versions | v1 and v2 (the “big spec”) |
| Bitrix24 instances | several, widget rolled out to all |
Under the thin Bitrix24 embed sits a Laravel service: the embed holds no business logic and serves a finished page. One service handles three CRM sections. Search across six registries fits into 300 ms thanks to ClickHouse, with a fallback to the regular database on failure. The second version cleared the accumulated load on task assignment and added caching. The assignment module is filed separately and configures on each instance.
Process and timeline
| Stage | Period | Result |
|---|---|---|
| Widget in amoCRM (predecessor) | 2022 | Documents by INN/OGRN + notifications in amoCRM |
| Bitrix24 CRM app concept | October 2023 | estimate 160–220 h, folded into a widget |
| Widget v1 in three sections | November 2024 → March 2025 | 133 h, live launch 3 February 2025, accepted 12 March 2025 |
| Status exchange with 1C | November 2024 | proposal, deferred by the client |
| Widget v2 (the “big spec”) | August–September 2025 | done 25 September 2025 |
| Task-assignment module | September 2025 | 10 h, shipped 29 September 2025 |
| Price System for Bitrix24 | Spring 2026 | Prototype, halted by the client’s partners |
Incidents and response
A widget in someone else’s portal is tested in failures, not in calm running. Two cases showed why the logic sits on our server.
The integration was wiped, restored in about 20 minutes. In August 2025 an outside portal administrator carelessly deleted the widget integration, knocking out the client id and secret along the way. From the message “our widget is gone” to confirmed full operation took about 20 minutes: we restored a backup of the config tables, fixed the keys in the database, and reconnected the app. The OGRN subscriptions survived. Following the case, we added a short recovery procedure to the documentation.
The widget went down across every instance at once. In December 2025 Bitrix stopped returning data the way it used to, and the widget went down on all the client’s instances at the same time. Reinstalling the app through the standard button restored operation, and we cleared the remaining 500 error the same day. The cause was on Bitrix’s side and hit every portal at once: exactly the class of problem the business logic is kept outside the embed for.
What we proposed but did not build
Honest status reporting is part of the work too. We had estimated exchanging document statuses between 1C and the platform back in 2024, but the client chose to defer it. When the idea came back in 2025, now at a volume of around 107 thousand declarations, we deliberately held off writing a spec until a viability test, and the task stayed at the check stage. A browser extension as a way around Bitrix’s limits on app installation (showing the widget by INN on any site) we proposed in 2024, and the idea stalled. The “Price System” product for Bitrix24 we took to a prototype, but the client’s partners did not back it, and the project was stopped on their side.
Team
- Anton Hersun, Xaver Pro — project lead, designed the “widget to service” contract. Built widget v1 (133 h) himself. For us this is a rare case where the project lead closes the build by hand: first we had to understand the mechanics of Bitrix24 from the inside, and only then draw the architecture.
- Widget-and-parser developer — took over the Bitrix track by the time of v2 and runs it onward (the second version and later refinements). Continuity inside the track holds: widget tasks go through one and the same person. The analytics panel is run by a different developer, with its own specialty in integrations and parsers.
Screenshots and materials
To be added in a separate pass: a screenshot of the widget inside a Deal card after privacy handling of specific companies.
If your Bitrix24 widget breaks on every portal update, we know the feeling. Show us the code and the list of “what broke in this release,” and we will say what to move to the server so portal updates stop taking the widget down. The review is free.