Інтеграція з Avito через API: автоматична синхронізація магазину

Чому магазин на маркетплейсі втрачає замовлення без синхронізації

Продали останню одиницю на сайті, а на маркетплейсі оголошення залишилося активним — покупець оформлює замовлення, ви підтверджуєте, товару немає. Скасування з вини продавця б'є по рейтингу, а алгоритм майданчика поступово опускає картки у видачі.

Це не разова накладка, а системний результат ручного оновлення оголошень: поки менеджер править залишки вручну, між каналами продажів накопичується розсинхрон каталогу.

Зворотна ситуація не краща: товар лежить на складі, але в картці стоїть нуль — продажі просто не відбуваються, і ніхто цього не помічає.

Додайте сюди дублі оголошень після повторного вивантаження, різні ціни в картці та в обліковій системі, замовлення, загублені між поштою, особистим кабінетом і CRM. Кожна така дірка — це не лише втрачений виторг, а й час співробітників на звірку вручну.

Інтеграція з Avito через API прибирає саму причину: залишки, ціни та статуси замовлень синхронізуються між магазином і майданчиком автоматично, за подіями, а не за розкладом чергового менеджера.

Синхронізація залишків спрацьовує в момент продажу в будь-якому каналі, тому картка не може продати те, чого немає, а замовлення з майданчика одразу потрапляє в облікову систему і не губиться в листуванні.

Далі розбираємо, як це закривається на рівні обміну даними і що саме ламається при ручній роботі.

Що дає автоматична синхронізація магазину

Синхронізація будується на зв'язці «облікова система — маркетплейс»: товар заводиться один раз, а далі картка, ціна, залишок і статус замовлення живуть в одному контурі.

Публікація нової позиції перестає бути ручною операцією — картка вирушає на майданчик у момент появи в каталозі, а не через день-два, коли в менеджера дійдуть руки. Для асортименту в сотні позицій це різниця між «виклали за вечір» і «викладаємо тиждень».

Точність залишків — другий вимірюваний ефект. Залишок списується за фактом замовлення і повертається при скасуванні або поверненні, тому розбіжність «на сайті одне, на майданчику інше» закривається як клас.

Саме на ньому зазвичай і втрачаються гроші: покупець оформлює позицію, якої вже немає, замовлення відвалюється, а картка отримує пониження у видачі.

Єдиний каталог прибирає ручну працю на підтримці: правка опису, характеристик або ціни робиться в одному місці й роз'їжджається по всіх каналах продажів.

Менеджери перестають звіряти таблиці й переносити дані руками — а отже, зникає і клас помилок, який виникає тільки при ручному перенесенні: друкарська помилка в ціні, забута позиція, застаріле фото.

Автоматизація продажів проявляється в обробці замовлень: нове замовлення підтягується в облікову систему, статус вирушає назад на майданчик, покупець бачить рух по замовленню без участі оператора.

Чим більше замовлень на день, тим помітніша різниця — ручний контур починає захлинатися саме на піках, коли втрачати замовлення найдорожче.

Перевірити ефект можна за чотирма точками: час від появи товару в каталозі до публікації, частка замовлень, скасованих через неактуальний залишок, кількість ручних операцій на одне замовлення і розбіжності між каталогом і майданчиком. Ці метрики знімаються до впровадження і після — за ними й видно, чи окупилася зв'язка.

Способи підключення: обмін файлами, API, посередник

Три способи відрізняються не «зручністю», а тим, де живе логіка зіставлення і як швидко магазин дізнається про зміну.

Під час обміну файлами ви формуєте вивантаження каталогу й віддаєте його за розкладом; під час роботи через API запити йдуть безпосередньо до маркетплейсу; проміжний сервіс бере на себе чергу, повтори й розбір помилок. Вибір диктує частота оновлення: залишки й ціни змінюються постійно, описи та фото — рідко.

На практиці найчастіше беруть API як основний канал, а проміжний сервіс надбудовують, коли точок продажу стає більше однієї. Файловий обмін залишається робочим рішенням для рідкісних вивантажень і разових звірянь — наприклад, під час перенесення каталогу або інвентаризації.

Обмеження методів варто закладати в архітектуру заздалегідь: ліміти запитів змушують групувати зміни й оновлювати позиції пакетами, а не по одній.

Тоді пік правок у каталозі не перетворюється на чергу відмов, а розходження між магазином і маркетплейсом закривається в межах одного циклу оновлення.

Як відбувається впровадження інтеграції з Avito

Впровадження починається не з коду, а з розбору поточного стану: як влаштований каталог, звідки беруться залишки, хто і як часто змінює ціни та описи.

На цьому етапі фіксуємо розбіжності між обліковою системою та тим, що вже опубліковано на майданчику, — саме вони дають дублі, «завислі» оголошення та продажі товару, якого немає в наявності.

1. Аудит каталогу та облікових даних. Звіряємо номенклатуру, категорії, одиниці виміру, правила формування цін і знижок. На виході — карта відповідності: які позиції публікуються, які приховуються, що робити з товарами без залишку.
2. Проєктування схеми обміну. Визначаємо, що є джерелом істини, у який бік ідуть дані та з якою періодичністю. Фіксуємо поведінку при конфлікті: якщо менеджер виправив оголошення вручну, а облікова система надіслала нове значення — хто перемагає.
3. Складання контуру синхронізації. Реалізуємо обмін залишками, цінами, статусами оголошень і замовленнями, обробку помилок і повторні спроби при збоях зв'язку. Окремо закриваємо ліміти майданчика, щоб сплеск оновлень не призводив до блокування запитів.
4. Тестовий контур. Проганяємо сценарії на обмеженій групі товарів: масове оновлення цін, обнулення залишку, повернення товару в наявність, скасування замовлення. Дивимося логи, звіряємо підсумковий стан каталогу з обліковою системою рядок за рядком.
5. Пілот на бойовому каталозі. Підключаємо реальні оголошення невеликою часткою асортименту, спостерігаємо повний цикл доби: нічні перерахунки, ранкові замовлення, ручні правки менеджерів.
6. Передача в експлуатацію. Розгортаємо моніторинг обміну, налаштовуємо оповіщення про розбіжності та збої, описуємо регламент дій при інциденті.
7. Навчання та регламенти. Передаємо команді інструкції: як додати товар, як тимчасово зняти його з публікації, що робити при розбіжності залишків.

Після передачі зв'язка працює без ручного втручання, а зміни в каталозі доїжджають до майданчика в межах заданого інтервалу. Опишіть ваше завдання — повернемося з оцінкою термінів і планом робіт за етапами.

Що замовник отримує на руки після запуску

Після запуску інтеграції у замовника залишається не «чорна скринька», а комплект артефактів, за яким систему можна передати іншій команді, розширити або підняти заново. Нижче — що саме фіксуємо в передачі.

• Налаштування зв'язки. Конфігурація обміну між магазином і Avito: доступи, ліміти запитів, розклад синхронізації, обробка помилок і повторних спроб. Усе винесено в окремий конфіг, а не «зашите» в код.
• Правила зіставлення товарів. Логіка, за якою позиції каталогу пов'язуються з оголошеннями: за артикулом, штрихкодом або складеним ключем, що робити при дублях і розбіжностях, як обробляються нові та зняті з продажу позиції.
• Схема обміну даними. Діаграма потоків: які поля йдуть в Avito, що повертається в магазин, де зберігається стан синхронізації і як вирішуються конфлікти при одночасній зміні.
• Документація інтеграції. Опис сценаріїв, форматів запитів і відповідей, точок розширення. Достатньо, щоб новий інженер розібрався без автора.
• Журнали обміну. Логи синхронізації з історією: що і коли пішло, що повернулося, які позиції відхилилися і чому. За ними розбирається будь-який збій без відтворення.
• Регламент підтримки. Що моніториться автоматично, які спрацьовують оповіщення, хто і в який термін реагує на збій, як виконується відкат.
• Інструкція з експлуатації. Покрокові дії для типових ситуацій: додати категорію, змінити правило зіставлення, перезапустити обмін, підключити новий магазин.

Кожен артефакт версіонується разом із кодом — при змінах правила і схеми оновлюються синхронно, а не розходяться. Опишіть вашу задачу — повернемося з оцінкою та планом передачі.

Кейс: як магазин перестав втрачати замовлення на маркетплейсі

Що було до синхронізації

Магазин торгував через Avito та власний сайт, а залишки вів вручну: менеджер вивантажував таблицю, правил її та заливав назад.

На піку продажів це давало до 18% позицій з розбіжністю — товар продавався на маркетплейсі, коли його вже не було на складі, або навпаки висів «в наявності» при нульовому залишку. Кожен такий випадок — скасоване замовлення, дзвінок покупцю та удар по рейтингу продавця.

Гіршою була затримка реакції: замовлення з маркетплейсу потрапляло в облікову систему тільки після того, як менеджер вручну переносив його з кабінету. Середній час до підтвердження — близько 40 хвилин у робочу зміну та до 9 годин у вихідні. За цей час частина покупців встигала оформити замовлення в конкурента.

Що змінили

Ми підключили інтеграцію з Avito через API: залишки та ціни йдуть у маркетплейс при кожній зміні на складі, а нові замовлення забираються з кабінету та заводяться в облікову систему автоматично.

Для спірних сценаріїв — резерв товару на час оформлення, повторна спроба при обриві зв'язку, журнал операцій з ідемпотентними ключами, щоб одне замовлення не задвоїлося.

Окремо налаштували правила розсинхрону: якщо позиція не підтвердилася, вона йде в чергу на розбір, а не «залипає» в невірному статусі. Менеджер бачить тільки винятки замість повної таблиці.

Результат впровадження

• Частка розбіжностей за залишками: з 18% до 1,2% — скасування через «немає в наявності» практично зникли.
• Час реакції на замовлення: з 40 хвилин до 2-3 хвилин, цілодобово, без вихідних.
• Ручні операції з вивантаження: скоротилися приблизно на 90%, менеджер переключився на роботу з клієнтами.

Через два місяці після запуску магазин перестав втрачати замовлення на маркетплейсі: спірні позиції розбираються точково, а не блокують всю вітрину.

Чим синхронізація через API відрізняється від вивантаження файлами

Вивантаження файлом — це пакетна операція: ви формуєте XML або CSV за розкладом, передаєте його в особистий кабінет або за посиланням, майданчик приймає файл цілком і обробляє його асинхронно.

Між двома вивантаженнями магазин живе в стані попереднього зрізу: ціна, залишок або статус оголошення змінюються лише після наступного прогону.

Якщо менеджер виправив залишок вручну в панелі, наступне вивантаження це перезапише — файл не знає, що відбувалося в системі після його формування.

API працює за подієвою моделлю. Зміна в обліковій системі (оплата, надходження товару, зміна ціни) ставить завдання в чергу, обробник надсилає запит до майданчика і фіксує відповідь.

Затримка даних вимірюється не годинами між вивантаженнями, а часом проходження черги — за нормальної роботи це секунди-хвилини. Частота синхронізації перестає бути параметром розкладу і стає властивістю потоку: оновлюється те, що реально змінилося, а не весь каталог.

Стійкість до збоїв — ключова відмінність. Файлове вивантаження при помилці розбору видає загальну відмову по всьому пакету: незрозуміло, яка позиція не пройшла і чому, доводиться звіряти вручну.

API повертає результат по кожній операції окремо, а збій мережі або ліміт запитів обробляється повтором із наростаючою паузою. Завдання не губиться: необроблені зміни залишаються в черзі і йдуть після відновлення зв'язку, а не відкочуються до стану останнього файлу.

Звідси різниця в обсязі ручних операцій. При файлах хтось має стежити за розкладом, розбирати протоколи помилок і вручну наздоганяти розбіжності. При API ручною залишається лише обробка винятків, які система не змогла розв'язати сама, — їхня частка на порядок менша.

Вибір між підходами — це вибір між «дані актуальні на момент вивантаження» і «дані актуальні на момент зміни».

Часті технічні питання щодо інтеграції з маркетплейсом

Інтеграція з Avito майже ніколи не починається з нуля: частіше у замовника вже працює рішення — самописне, на боці підрядника або зібране з готових модулів.

Ми не ламаємо те, що тримає продажі: спочатку розбираємо поточні сценарії обміну, точки відмови та те, як каталог зіставляється з категоріями площадки.

Далі або розширюємо наявну інтеграцію, або переносимо її на підтримувану архітектуру — зі збереженням історії замовлень і зв'язків між картками.

Окрема тема — кілька площадок і нестандартний каталог. Коли магазин торгує не лише на Avito, а ще на маркетплейсах і у власному інтернет-магазині, важливо не плодити дублі товарів і не втрачати залишки.

Ми будуємо єдиний шар синхронізації: одне джерело правди щодо номенклатури, цін і стоків, а площадки отримують дані через свої адаптери.

Нестандартні каталоги — набори, послуги, товари під замовлення, складні одиниці вимірювання — описуємо правилами зіставлення, а не ручним редагуванням кожної позиції.

Ліміти звернень і збої обміну — не аварійна ситуація, а штатний режим роботи із зовнішнім API. Тому в інтеграції заздалегідь закладені черги запитів, повторні спроби з наростаючою паузою та ідемпотентність операцій: повторне надсилання не створює дубль оголошення чи замовлення. Якщо площадка недоступна, зміни накопичуються локально й ідуть в обмін, щойно зв'язок відновився.

Чи можна синхронізувати Avito та інші площадки з однієї системи?

Так. Ми виносимо спільний шар синхронізації: номенклатура, ціни та залишки ведуться в одному місці, а кожна площадка підключається своїм адаптером. Це прибирає розсинхрон залишків і ручне дублювання карток між каналами продажів.

Що буде при збої обміну або перевищенні лімітів звернень?

Запити ставляться в чергу з повторними спробами та наростаючою паузою, операції ідемпотентні — повтор не створює дублів. Зміни, що не пішли на площадку, зберігаються локально й надсилаються після відновлення зв'язку, а розбіжності потрапляють у звіт для розбору.

Обговоримо ваше завдання синхронізації магазину

Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібно зрозуміти вашу схему роботи з Avito: скільки активних оголошень, у скількох категоріях, як часто змінюються ціни та залишки, хто зараз оновлює їх вручну.

Від цього залежить і обсяг інтеграції з Avito, і терміни впровадження — синхронізація каталогу на кілька сотень позицій і обмін замовленнями з кількома складами потребують різної архітектури.

На розборі задачі уточнюємо ключове: які дані йдуть з вашої облікової системи в Avito, а які повертаються назад — замовлення, статуси, відгуки, повідомлення покупців.

Перевіряємо, чи є у вас доступ до API та права на потрібні методи, як влаштовано облік залишків і що відбувається при розсинхронізації.

Окремо проговорюємо сценарії збоїв: що робити, якщо оголошення зняли з публікації, а товар ще в наявності, або якщо замовлення надійшло в момент оновлення ціни.

За підсумками розмови ви отримуєте:

• схему обміну даними між вашою системою та Avito із зазначенням напрямків і частоти синхронізації;
• перелік методів API, які задіємо, та обмежень, які вони накладають на логіку;
• план робіт за етапами: підготовка доступів, розробка обміну, тестовий контур, виведення в робоче середовище;
• реалістичні терміни впровадження з розбивкою за етапами та точками, де потрібна ваша участь;
• склад підтримки після запуску: моніторинг обмінів, обробка помилок, реакція на зміни на стороні Avito;
• список даних і доступів, які знадобляться від вас для старту.

Наступний крок — коротка розмова по суті: опишіть задачу, поточний процес і вузькі місця, а ми повернемося з оцінкою, планом робіт і термінами.

Якщо частина процесів ще не формалізована, це не блокер — розберемо на місці та запропонуємо, як закрити синхронізацію без перебудови всього обліку.