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

Вранці товар з'явився на Avito, до обіду — зник. Ліміт запитів? Помилка OAuth? Або дублікат? Ручна інтеграція — джерело таких збоїв. Багато магазинів стикаються з проблемами синхронізації: неправильний формат XML, перевищення лімітів, скидання токенів. Замість автоматизації отримують головний біль. Наприклад, нещодавно до нас звернувся клієнт з каталогом 5000 товарів. Вони вручну оновлювали ціни на Avito після кожної зміни в обліковій системі. У результаті 20% оголошень містили застарілі ціни, а 15% були заблоковані через дублікати. Автоматизація через API вирішила ці проблеми за тиждень. Економія склала 30% часу на модерацію та зниження витрат на ручну працю на 70%. Інтеграція окупається за 2-3 місяці завдяки автоматизації. Ми вирішуємо це завдання підключенням через API Avito, виключаючи ручне керування та втрати даних. За більш ніж п'ять років ми виконали 30+ інтеграцій — гарантуємо стабільну роботу та підтримку після запуску. Наш підхід — використовувати офіційний API Avito з правильною обробкою токенів і лімітів.

Які проблеми вирішує інтеграція з Avito через API?

Помилки аутентифікації: неправильно налаштований OAuth2 призводить до блокування запитів. Ми використовуємо правильний grant_type і автоматично оновлюємо токен після закінчення терміну. В одному проєкті клієнт забув налаштувати refresh_token — інтеграція працювала лише 24 години, поки токен не закінчився. Дуби оголошень: без контролю id товару Avito створює копії. Наша система звіряється за артикулом і оновлює існуюче оголошення, що економить до 30% часу на модерації. N+1 запити: масове розміщення без батчингу викликає ліміти API. Ми групуємо запити та використовуємо паузи між ними, що дозволяє вивантажувати до 1000 товарів за годину без блокування.

За даними Документація Avito API, оновлення через XML-фід займає до 24 годин, тоді як API працює в реальному часі. Це означає, що при зміні ціни в магазині на Avito нове значення з'являється через секунди, а не наступного дня.

Чому API Avito краще за XML-фід?

API Avito оновлює оголошення в реальному часі, тоді як XML-фід — раз на добу. Швидкість оновлення вища в 24 рази. Крім того, API дозволяє керувати ставками та статусами, що неможливо при XML. Для динамічного асортименту API незамінний.

Як ми це робимо

Використовуємо стек: Laravel 11, PHP 8.3, Guzzle для HTTP-клієнта, Redis для кешування токенів. Приклад реалізації аутентифікації через OAuth2:

class AvitoClient
{
    private string $accessToken;

    public function authenticate(): void
    {
        $resp = Http::post('https://api.avito.ru/token', [
            'client_id'     => config('services.avito.client_id'),
            'client_secret' => config('services.avito.client_secret'),
            'grant_type'    => 'client_credentials',
        ]);

        $this->accessToken = $resp->json('access_token');
    }

    private function request(string $method, string $path, array $data = []): array
    {
        return Http::withToken($this->accessToken)
            ->{strtolower($method)}('https://api.avito.ru{$path}', $data)
            ->json();
    }
}

Розміщення оголошення виконується методом createListing. Код обробляє категорії, зображення та контакти.

Авторизація через OAuth2

Avito використовує протокол OAuth2. Ми отримуємо токен через client_credentials, автоматично оновлюємо його після закінчення терміну. Це забезпечує безперебійну роботу без ручного втручання.

Процес роботи

1. Аналітика: вивчаємо каталог, вимоги до синхронізації, частоту оновлень.
2. Проєктування: обираємо спосіб (API або XML), проєктуємо архітектуру інтеграції.
3. Реалізація: пишемо код на Laravel, налаштовуємо OAuth2, тестуємо на пісочниці Avito.
4. Тестування: перевіряємо масове вивантаження, обробку помилок, коректність статусів.
5. Деплой: розгортаємо на продакшені, налаштовуємо моніторинг, надаємо доступ.

Типові помилки, які ми запобігаємо

• Неправильне налаштування часової зони для планувальника завдань — призводить до пропуску оновлень.
• Відсутність обробки ліміту запитів (429 Too Many Requests) — інтеграція падає при масовому завантаженні.
• Ігнорування змін схеми API Avito — зламане вивантаження після оновлення платформи.

Терміни та що входить у роботу

У базовий пакет входить:

• Налаштування OAuth2 та отримання доступів.
• Розробка модуля вивантаження (товари, ціни, залишки).
• Інтеграція з вашою CMS (WordPress, Laravel, 1С-Бітрікс та ін.).
• Тестування на реальних оголошеннях.
• Документація з експлуатації.
• Підтримка 2 місяці після запуску.

Чому варто довірити інтеграцію нам?

• Досвід більше п'яти років, 30+ успішних проєктів.
• Використовуємо офіційний API Avito, гарантуємо відповідність вимогам.
• Надаємо гарантію на код 6 місяців та оперативну підтримку.

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

Ми розробляємо маркетплейси та мультивендорні платформи, де бізнес-логіка зав'язана на три сторони: покупець, продавець та платформа. Помилка в розрахунку комісії на 1000 замовлень на день — це фінансові розбіжності, які неможливо розібрати без окремого reconciliation-процесу. Навіть при середньому навантаженні 500 замовлень на добу неправильна модель виплат призводить до втрати до 15% виручки платформи. Ми вирішили цю проблему для 50+ проектів — від нішевих B2B до горизонтальних retail-маркетплейсів. Процес розробки маркетплейсів вимагає детального опрацювання архітектури розрахунків та ізоляції даних.

Як побудувати надійну мультивендорну платформу?

Як уникнути розбіжностей у розрахунках комісій

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

Моделі комісій (використовуємо одну з або комбінуємо):

Ми використовуємо Stripe Connect як базовий стандарт. Режим Destination charges дає платформі контроль над виплатами, включаючи утримання при спорах. Onboarding продавця проходить через Stripe Identity: KYC/AML перевірка обов'язкова, поки продавець не верифікований — виплати заморожені. Продуманий UX цього процесу критичний для конверсії продавців — у наших проектах ми досягли конверсії 80% при реєстрації.

Чому архітектура мультиарендності критична для ізоляції даних

Перший крок — вибір архітектури мультиарендності. У shared-schema режимі всі продавці в одних таблицях з vendor_id. Ми обов'язково впроваджуємо Row Level Security на рівні PostgreSQL та глобальні scopes в ORM (Laravel, Rails, Django). Це гарантує, що продавець не побачить чужих замовлень навіть при помилці розробника. Для enterprise-проектів з жорсткими вимогами GDPR використовуємо окремі схеми PostgreSQL — ізоляція строгіша, але cross-vendor аналітика складніша.

Як реалізувати складські залишки без race condition

Два покупці одночасно додають останній товар у кошик. Хто його купить? Застосовуємо optimistic locking при створенні замовлення:

UPDATE inventory 
SET reserved = reserved + 1 
WHERE product_id = ? AND (quantity - reserved) >= 1

Атомарна операція — другий запит поверне 0 зачеплених рядків та отримає помилку «товар закінчився». Типова схема для високонавантажених маркетплейсів.

Який підхід до каталогу товарів обрати: unified чи per-vendor?

Порівняння підходів до каталогу товарів:

Для нішевого B2B маркетплейсу ми частіше обираємо per-vendor — швидше запускається. Для горизонтального retail з сотнями продавців — unified-каталог дає кращий UX.

Пайплайн модерації: автоматика та ручна верифікація

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

1. Автоматичні перевірки при публікації: обов'язкові поля, відповідність категорії, стоп-лист слів, дублікати через хеш зображення.
2. AI-класифікація (Amazon Rekognition або Vertex AI Vision) — детекція забороненого контенту та визначення категорії.
3. Черга ручної перевірки для flagged товарів.

Статусна машина: draft → pending_review → active / rejected → suspended. Кожен перехід — подія з причиною та модератором. Продавець отримує сповіщення з конкретною причиною відмови, а не «порушення правил». Верифікація відгуків обов'язкова — тільки після підтвердженого замовлення. Автоматичний детектор флагує різке зростання відгуків від акаунтів з нульовою історією.

Пошук та рекомендації

Пошук по маркетплейсу з різними продавцями та сотнями тисяч товарів — це Elasticsearch або OpenSearch, не SQL LIKE. Векторний пошук для семантики, фасетна фільтрація через агрегації. Персоналізована стрічка на основі колаборативної фільтрації. A/B тестування алгоритмів ранжування обов'язкове — інтуїція тут поганий порадник.

Процес роботи

Маркетплейс — ітеративна розробка. MVP: реєстрація продавців, каталог товарів, кошик та checkout через Stripe Connect, базова модерація. Після запуску — дані про реальне використання визначають пріоритети наступних ітерацій.

Типовий порядок:

• MVP (3–4 місяці)
• Аналітика та зворотний зв'язок
• Перший розширений реліз (2–3 місяці)
• Масштабування та оптимізація

Терміни та вартість

• MVP маркетплейсу (каталог, checkout, базові профілі продавців): 3–5 місяців.
• Повнофункціональний маркетплейс з модерацією, розширеною аналітикою, мобільним додатком: 8–18 місяців.
• Додавання маркетплейс-функціональності до існуючого e-commerce: 2–5 місяців.

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

Що входить в роботу

• Проектна документація: архітектура, схеми даних, API-специфікації (OpenAPI).
• Доступи до репозиторію, CI/CD, документації з розгортання.
• Навчання команди замовника роботі з платформою.
• Технічна підтримка протягом першого місяця після запуску.

Ми гарантуємо коректність фінансових розрахунків та конфіденційність даних. Архітектурні принципи, на яких ми ґрунтуємося, підтверджені досвідом 10+ років та 50+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.