Avito API and Open Channels: where the message chain breaks
The flow of messages from listing chats arrives via Avito API separately from the channels that Bitrix24 Open Channels sees.
A message exists as an object with a dialog ID, attachments, and read status, but until this flow is converted into a ticket inside the system, there is no conversation for the business — it lives in the platform app on the manager's phone.
The break appears already at the data model level. A chat is tied to a specific listing, not to a person: one buyer who writes about three items creates three independent dialogs, which in Open Channels do not merge into a single ticket.
The distribution rule does not trigger, no assignee is set, the history does not reach the customer card, and the next manager starts the conversation from scratch.
The second point of loss is the delivery method.
If the Avito integration with Bitrix24 is built on email notifications, the reply goes from the mailbox, not from the line: there is neither first response time, nor quality control, nor preservation when an employee changes or goes on vacation.
Tickets close silently — simply because no one knew about them, while the report shows a smooth flow that never existed.
Hence the cost: what is lost is not the channel, but the conversion from a ticket to a reply.
We will break down how to connect listing chats, dialog IDs, and Bitrix24 Open Channels so that a ticket appears in the system before the manager opens the platform, and so that not a single lost ticket goes unnoticed.
What changes after connecting the channel to Open Channels
The Avito channel, once connected, becomes another source in Open Channels: dialogs enter a unified ticket queue along with emails, website chats, and messengers.
The employee does not need to keep the seller account open — the reply is sent from the card, and the history stays next to the contact and deal.
Technically, connecting Avito to CRM is built on Avito API: key-based authorization, subscription to new message events, and matching listings to dialogs.
An incoming message is linked to a contact by phone number or profile ID, so the conversation does not split into separate threads, and the customer is visible in full — from the first question to the deal.
First response speed no longer depends on who noticed the message first: the queue distributes tickets according to rules, assigns an owner, and highlights overdue ones.
The manager gains control over conversations — dialogs are visible in reports instead of remaining on managers' personal phones.
A separate class of failures — "ticket did not reach the employee" — goes away. If an external service is unavailable, the event is not lost but retried from the queue, and if the connection breaks, the dialog is rebuilt from history. This is the difference between "channel connected" and "channel works."
Options for connecting Avito API to Open Channels
Bitrix24 Open Channels accept a dialog through a channel, and there is no ready-made channel for Avito out of the box — it has to be built.
Before choosing a scheme, two properties of Avito API are taken into account: some message events are retrieved by periodic polling rather than arriving on their own, and the access token has a limited lifetime, requiring refresh. This gives three workable alternatives with different capability ceilings.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made module from Marketplace | Fast launch, one Avito account, standard conversations | Works according to the author's logic: routing rules and dialog distribution among employees cannot be changed. When Avito API methods change, the channel breaks until an update is released |
| External intermediary service | Multiple accounts and platforms, a single entry point needed, no in-house support | Conversations and tokens pass through third-party infrastructure, adding delivery delay and plan limits; fine-grained routing by channel is unavailable |
| Custom scheme on Avito API | Non-standard routing, high load, history retention requirements | We handle authorization, token refresh, rate-limit and retry processing, and matching a dialog to a contact and deal ourselves |
The difference shows under load, not at launch: with a stream of tickets, a module or intermediary starts delivering messages with delay, whereas a custom scheme queues requests and routes dialogs according to rules.
The choice depends on the number of Avito accounts and how tickets are currently distributed among managers.
Implementation sequence: from conversation audit to handover
Integration implementation starts not with connecting a channel but with analyzing how tickets arrive now: conversation volume, peak hours, share of standard questions, first response time.
Without these numbers, routing is built at random and falls apart under the first load, so the audit is the first stage.
- Conversation audit. We export the ticket history from Avito, count volume and topics, and note where dialogs break off without a reply.
- Scheme design. We define Open Channel queues, topic owners, and escalation rules if an operator is silent.
- Connection setup. Access rights to the software interface, linking conversations to customer cards — history is not lost when an operator changes.
- Ticket routing setup. Distribution by channel, topic, and shift load; separate queues for service and procurement.
- Channel testing. Test tickets verify delivery, attachments, duplicates, getting into the right queue, and response time.
- Handover to operation. Regulations for operators, team training, a metrics dashboard, and a rollback plan to manual mode.
After launch, for the first weeks we run the channel together with the customer's team: we make changes to distribution rules based on facts from real dialogs, not assumptions. At the end, a working scheme, documentation, and people who can maintain it without us remain.
Documents and settings that remain with the customer's team
An integration that relies on one engineer lasts until their vacation. Therefore, handover is not a final formality but a separate stage of work: the customer's team receives everything needed to change routes, onboard new operators, and troubleshoot failures without us.
What remains in the project after handover:
- Working channel configurations: access keys, endpoint addresses, linking the Avito account to Open Channels — with a note on where they are stored and in what order they are updated.
- Route scheme: which queues are created, by what rule a dialog reaches an operator, what happens on no answer and outside business hours.
- Employee access rules: roles and rights in chats, who sees conversation history, what is disabled on the day of termination.
- Chat handling regulations: first response deadlines, standard message templates, escalation procedure to the manager.
- Integration documentation: entity map, mapping of listing and deal fields, failure points, and where to view the event log.
- Instructions for operators: connecting to the line, troubleshooting common errors, what to do if a dialog did not arrive in chat.
- Failure procedure: who checks the channel and in what sequence, how to restore the previous configuration.
- Change log: what was changed in the settings and why, so a fix does not have to be reconstructed from memory.
Case study: how listing chat conversations became part of the funnel
What was before integration
Requests from listings lived in a separate window: the manager opened classifieds chats, copied the text into CRM, and replied from the account. Conversation history was not saved anywhere, and when the shift changed, the new employee started the dialog from scratch.
On peak days, several hundred tickets came into the line, and they could not be processed manually in time.
Metrics before: about 70% of dialogs were handled entirely manually, average first response time was 3-4 hours, and by the end of the week 12-15% of tickets were closed without any reply. No one counted losses: it was not visible how many customers went to competitors.
What was changed
The integration case was built around one principle — a listing chat should become an ordinary ticket in the funnel. We connected Avito to Bitrix24 Open Channels via Avito API: each message automatically creates a ticket, links to a contact, and is distributed according to rules.
We added templates for frequent questions, an out-of-hours auto-reply, a response timer, and escalation to the manager if a dialog hangs without a reply.
What became
First response — 4-6 minutes instead of hours, share of missed tickets — 2-3%. Manual operations decreased severalfold: the manager works in one window, and the conversation remains in CRM, so an employee leaving no longer breaks the dialog.
Chat automation produced a side effect — for each listing, you can see how many tickets it brought and at what stage customers are lost.
How does a ready-made module differ from a custom connection?
A ready-made module is a pre-defined scenario: a ticket from a listing chat enters an Open Channel, is matched to a contact, and the manager sees which listing the customer is writing about. It is installed from the app catalog and covers a standard ticket flow without development.
The limit begins where the process diverges from the standard.
Routing by region, category, and manager load; merging a dialog with an existing deal; populating fields from the listing card; separating first-time and repeat tickets — the module either cannot do each item or does it in one hard-coded way that cannot be overridden. This is where the risks of ready-made solutions begin: closed code and dependence on the author.
A core update breaks the module, support stops, and there is no way to understand why some messages are lost — no logs, no extension points.
Rate limits and duplicate delivery come up separately: without matching by message ID, one dialog generates duplicate tickets and leads in CRM.
A custom connection works differently: we handle Avito API events ourselves, pass them to Bitrix24 Open Channels, and define routing rules, failure retries, and exchange logging.
The scheme is justified when there are many tickets, and accounting and distribution are unique — and when predictability during updates matters.
The choice of integration method comes down to one question: how much your process differs from the standard. If there are no differences, a module is enough and launch takes days.
If differences in routing, reporting, or accounting are fundamental, a custom scheme is more reliable than layering modifications on top of someone else's code.
Common technical questions about connecting the channel
Before channel acceptance, what is checked is not the sales scenario but the system's behavior in non-standard situations: what happens to conversations when disconnected, how the line will divide the flow between departments, why a message sometimes does not arrive instantly. Below are the doubts that come up most often during a test connection.
Can multiple Avito accounts be connected to one Open Channel?
Yes, each account is created as a separate channel, but they all feed into one line. The dialog card shows which account the request came from, so distribution rules and reports are calculated across the combined flow, not separately for each channel.
What happens to conversation history if the channel is disconnected?
The archive remains in Bitrix24: dialogs, attachments, and deal links are preserved. Disconnection stops only the receipt of new messages. Messages sent during the pause are fetched by a separate synchronization on reconnection — they are not lost but arrive with a delay.
How does the line distribute tickets between departments?
The queue is configured by departments and groups: a ticket goes either into a common pool or directly to a specific department, then to the first available operator. If there are multiple accounts, the ticket is distributed once, and duplicates for one dialog are excluded.
Are there delays in message delivery?
The main technical limitation is the rate limits on the number of requests to Avito API: with a large number of accounts, polling runs at an interval, so in the first minutes after a listing is published the delay is more noticeable.
In normal mode, a message appears in the line within seconds, and peak spikes are smoothed by the processing queue.
Let's discuss the task: what is needed to connect your channel
The start of connection takes less time when the inputs are collected in advance: we do not have access to your account, and each clarification is a separate round of correspondence. Below is what actually affects the integration scheme and scope of work.
- A link to the Avito account and confirmation of access to conversations on listings, not just to statistics. If access is restricted, setup is done in your presence or through a separate user with the required rights.
- A list of listings or categories that must reach Open Channels, and their routing rule: common queue, specific department, or responsible employee for each area.
- The current channel scheme in Bitrix24: which lines are already working, how distribution is arranged, and whether the required queues are occupied by other ticket sources.
- A test listing and account for checking message receipt and replies. We perform the check on an isolated channel so as not to affect live dialogs with buyers.
- How tickets are processed today: deal stages, reply templates, what counts as a missed ticket and who receives notification about it.
- An engineer contact on your side and a window for verification. An incoming message arrives as an external call from Avito API — it is better to make sure the event arrives and is correctly identified before launch, not on the first business day.
Describe the task in free form and attach what you already have: we will come back with an estimate and work plan — scope of setup, sequence of stages, timelines, and the set of checks before launching the sales channel.