Certification analytics widget in amoCRM: documents by tax ID and subscriptions in a month

The client runs two tools: amoCRM as the sales managers’ main window, and our platform, which covers in-house analytics on product certification. Without integration the manager lives in two windows. One holds the deal card, the other the counterparty analytics, and the tax ID gets carried by hand from the first to the second. The widget was meant to fold those windows into one.

We built what was signed off and closed by acceptance act: a widget in the card plus a subscription-and-alert engine. A few widget extensions were priced in hours, but the client never released them for work, and the case shows those too. Two years later the client decided not to renew amoCRM and to move to Bitrix24, and the widget was decommissioned on schedule. An honest ending: the integration lasted exactly as long as the CRM itself did on the client’s side.

Snapshot

The problem

A manager opens a deal card in amoCRM. To see how many certificates and declarations a company holds and under which technical regulations, the manager has to go to another window and copy the tax ID across. Once a day, that’s tolerable. 30 times a day, it is not.

The fork that shaped the architecture came out of the correspondence right away. We first proposed showing the summary in the right column of amoCRM, in the native widgets, but there is little room there: full analytics does not fit. So we settled on a separate widget. It recognizes the tax-ID field in the card and shows a popup with data from our platform.

The second layer of the task: not a one-off view but tracking. The manager needs to learn when a tracked company gets a new document, not just see the current picture. That is no longer a widget but a subscription: a set of “user — tax ID” pairs, monitoring of new documents under those IDs, and delivery of alerts into amoCRM and to the account email.

There was a third request, from the client’s side: show the last document date right in the deal list, across all ~30,000 cards, without opening them. We priced it separately, covered below.

Why this is hard. The widget itself is not hard to write in amoCRM. Making it run every day without breaking is hard, when amoCRM changes its API access rules and the client-side portal lives its own life. For example, amoCRM refuses on security grounds to tell the widget which user is currently working in the system. That limit has to go into the subscription model itself: who sees the icon next to a tax ID, who gets a popup alert, and who reads it only in the shared list. Skip that conversation up front, and the managers decide that “alerts don’t arrive”, when they do.

How we did it

1. A thin widget: all the logic on our side.
The widget in the card does the minimum: it pulls the tax ID and sends a request to our Laravel server. The server goes into the in-house platform, gathers analytics on the counterparty (count of certificates and declarations, technical regulations, trend), and returns a finished page. No business logic lives inside amoCRM at all, only the embed. A deliberate choice: any CRM update breaks whatever sits inside it, so as little as possible should sit inside. There is a small delay before the popup opens while the widget waits on the database.

We also handled a data quirk separately: in Kyrgyz registers a counterparty carries only a tax ID, in Russian ones a registration number, but they are effectively the same identifier. The server searches both the Russian and the Kyrgyz tables.

2. A window that must not get in the way of CRM work.
The widget shows its window over the card, and it competes for screen space with amoCRM itself. From manager feedback in the very first week, we taught the window to resize, move freely across the screen, remember its size on the next open, and collapse to a strip so it does not block work on the deal. A small thing, but without it people simply stop using the widget.

3. The subscription engine: a set of “user — tax ID” pairs.
On top of the view we built tracking. The manager subscribes to a counterparty by tax ID, and the “user — tax ID” pair is unique in the system: if the same ID is tracked from another deal, the system catches it and warns, rather than creating a silent duplicate. Once a day the engine checks the tracked IDs against new documents in the platform. A document appears, and the alert goes to the responsible manager, both inside amoCRM and to the account email, and a click takes the manager straight into the right deal.

4. Two versions in a month, with an honest downtime warning.
The first widget version, still without alerts, launched on 8 August 2022. The alert system took 2 more weeks, and on 23 August we switched amoCRM from the first version to the second. We switched live, on the working portal, so we warned the client up front: during the version migration there may be temporary glitches, and the test alerts in that window are not real. The work was accepted and closed by acceptance act on 2 September 2022, with no complaints about alerts.

5. Where we hit an amoCRM limit.
On the day we switched to the second version, the widget stopped opening for some users. We found it fast. Some clients were still hitting the old address, which a page refresh cured, but the root cause sat deeper: the widget asked amoCRM via api v4 users which user was in the system, and amoCRM answered “lookup forbidden”. This is not a bug but the platform’s policy, and the alert model had to be built around it: the user currently in the system under their own login sees the icon next to the tax ID and the popup alert, the rest read the same thing in amoCRM’s shared notifications section.

What stayed at the estimated stage

Not everything discussed on this integration reached launch. Two extensions were priced in hours and handed to the client to decide, and that is where they stayed. We show them honestly, because the “estimate → sign-off → work” discipline runs both ways: if the client did not sign off, work does not start.

Last document date in the deal list (26 h, not launched). The client’s side wanted to see the last issued document’s date right in the amoCRM kanban list, across all ~30,000 deals: the manager picks a company to work without opening the card. We designed the solution without a widget. A separate “last document date” field is added to the card, a script pulls the list of all active deals through the amoCRM API, attaches them to date monitoring by tax ID, and updates the cards once a day through the same API. We flagged the risk separately: we still had to check whether amoCRM would even allow updating 30,000 cards in one pass. The estimate came to 26 hours. The client’s answer: “we’ll think about it.” The task stopped there.

Syncing the applicant database with amoCRM (80 h, stalled at sign-off). A standalone spec: export applicants from our platform into amoCRM as deals, sorted into pipelines (“Applicants”, “RF Manufacturers”, “KZ”, “DFO”), with a cutoff for companies holding fewer than 3 documents in 2 months, so the CRM does not fill with noise. We estimated it at 80 hours and drew up a plan and addenda. It never reached launch: sign-off dragged, and part of the team was relocating in that period, so the start kept sliding. The spec stayed at the sign-off stage.

Incident: a 404 on the Kazakh portal

9 months after launch, in May 2023, a complaint came in: the widget lags, and on the Kazakh portal it returns a 404 on every card, while in Russia everything works. The geography pointed the way. The widget encodes the data of the account sending the request, and for this specific Kazakh account part of that data was missing, which is where the 404 came from on exactly that portal. We requested access to the problem account, looked at what was missing in the encoding, and fixed it. We left the Russian portals alone: the problem was local, in one account.

Ending: a move off amoCRM to another CRM

The integration’s story ended not with a breakage but with a platform switch on the client’s side. In May 2024 the client decided not to renew amoCRM past 29 May. With the CRM gone, everything tied to it goes too: in June we proposed turning off the widget and its server-side processing, so we did not keep live code under a dead system, and on 21 June 2024 the widget was decommissioned.

The client did not lose the analytics in the cards. The line moved to Bitrix24, and the same “thin widget, logic on our server” principle became the base of a new widget under Bitrix, a separate story and a separate case. What matters here is different: the amoCRM integration served its term and closed cleanly, with no abandoned code and no stuck processes on someone else’s portal.

Results

Process and timeline

Team

• Anton Hersun, Xaver Pro — project manager: design of the widget and the subscription model, working through the amoCRM limits, launching versions live on the working portal, the incident analysis, and the decommission.
• Analytics-panel developer — the Laravel server side: counterparty analytics aggregation, the subscription engine, and alert delivery. The amoCRM integration belongs to the analytics-panel line, and this developer has run it from day one. The same person who writes the changes holds the context of how the tax-ID lookup works on our side, so it never has to be handed between people.

Screenshots and materials

To be added in a separate pass.

If your amoCRM and your in-house analytics drift into separate windows, and managers carry registration numbers by hand, send us a database export. We’ll see which links can be stood up without moving your infrastructure. The review is free.

Connect amoCRM and analytics →