Break down the Bitrix24 funnel and find the leads you lost

The agent reaches the portal through an inbound webhook: its URL already carries both the address and the key, so requests go as REST methods like crm.deal.list straight into your Bitrix24, cloud or self-hosted. It reads deals, leads, contacts, companies and invoices, computes stage-by-stage conversion, rep activity for the period and closed amounts. Long lists are fetched page by page, and the portal can push events about deal creation and changes itself — then a reaction does not wait for the next poll.

The funnel in Bitrix24 is torn in two: a lead and a deal are different entities, and converting a lead gives birth to a deal, a contact and a company at once. Counting conversion on deals alone means losing the top of the funnel, so the agent ties a lead to whatever it turned into. Stages are not universal either: every deal direction has its own set, and part of the meaning sits in custom fields — the agent reads those alongside the standard ones.

For writes the agent creates tasks with a deadline and context and moves deals between stages, re-reading the card first: the portal does not lock a record against parallel edits. Before creating a contact or a company it looks for duplicates by phone and email: a repeat lead in Bitrix24 blocks nothing and happily lands on top of the existing base. Bulk import and duplicate search run noticeably slower than ordinary requests — the portal answers such methods reluctantly, and waiting beats running into a refusal.

The webhook link is stored encrypted and is revoked in the same Developer resources, Other section; the portal asks for no separate authorization — the key rides inside the URL of every request. The request rate is kept low: the portal quota is shared with every other integration at once, so long selections are walked page by page rather than pulled in one go. If a method is closed by permissions or there were no deals in the period, it says so directly instead of handing over an empty table.