Інтеграція інтернет-магазину з СберМегаМаркет (API)

Інтеграція інтернет-магазину з СберМегаМаркет (API)

Десятки замовлень щодня скасовуються через розсинхронізацію залишків на вітрині СберМегаМаркет. Ручне оновлення цін по 2000 SKU забирає 6 годин на день — цей час можна витратити на розвиток бізнесу. Помилки в описах, невірні ціни та нульові залишки призводять до втрати доходу та зниження рейтингу магазину. Ми автоматизуємо цей процес через REST API та YML-фід. Наша команда має понад 5 років досвіду та реалізувала 50+ проєктів з інтеграції з маркетплейсами. Ви отримуєте повну синхронізацію за 6–10 робочих днів з гарантією стабільної роботи.

Які задачі вирішує інтеграція з СберМегаМаркет?

• Ручні помилки: описки в цінах, дублі товарів, нульові залишки — автоматизація знижує частку помилок до <1%.
• Затримки оновлення: товари на вітрині застарівають до моменту ручного вивантаження. REST API оновлює дані за секунди, що в 100 разів швидше за YML-фід, який оновлюється раз на добу.
• Втрата замовлень: відсутність габаритів або ваги блокує відправлення. Ми передаємо повні характеристики, включаючи габарити та вагу, щоб замовлення не зависали.
• Технічні ліміти: API СберМегаМаркет обмежує частоту запитів. Налаштовуємо повтор з експоненційною затримкою та черги для надійного завантаження.

Технічна реалізація

Аутентифікація та базовий клієнт

Для роботи з API СберМегаМаркет потрібен токен доступу. Ми зберігаємо його в захищеному конфігу та використовуємо єдиний HTTP-клієнт.

class SberMegaMarketClient
{
    public function request(string $method, string $path, array $data = []): array
    {
        return Http::withHeaders([
            'Authorization' => config('services.sbermm.token'),
            'Content-Type'  => 'application/json',
        ])->{strtolower($method)}(            "https://api.sbermegamarket.ru/api/merchantmanagement/v2{$path}",
            $data
        )->json();
    }
}

Вивантаження товарів через YML-фід

СберМегаМаркет приймає YML-фід — стандарт Yandex Marketplace Language. Формат простий, але важливий порядок полів та кодування UTF-8.

<?xml version="1.0" encoding="utf-8"?>
<yml_catalog date="поточна_дата">
  <shop>
    <name>Мій магазин</name>
    <offers>
      <offer id="SKU-001" available="true">
        <name>iPhone 15 Pro 256GB</name>
        <price>89990</price>
        <currencyId>RUR</currencyId>
        <categoryId>101</categoryId>
        <picture>https://example.com/images/iphone.jpg</picture>
        <description>Новий, гарантія 1 рік</description>
        <vendor>Apple</vendor>
        <vendorCode>MTP63ZP/A</vendorCode>
        <count>5</count>
      </offer>
    </offers>
  </shop>
</yml_catalog>

Керування цінами та залишками через REST API

Для оновлення цін та залишків використовуємо єдиний метод price-and-stocks. Один запит оновлює до 500 товарів, що економить час та знижує навантаження.

public function updatePricesAndStocks(array $items): void
{
    $offers = array_map(fn($item) => [
        'offerId' => $item['sku'],
        'price'   => $item['price'],
        'stocks'  => [['warehouseId' => $this->warehouseId, 'count' => $item['stock']]],
    ], $items);

    $this->request('POST', '/offers/price-and-stocks', ['offers' => $offers]);
}

Обробка замовлень

Отримуємо замовлення в статусі AWAITING_PACKAGING і одразу підтверджуємо відвантаження з трек-номером.

public function getOrders(string $dateFrom): array
{
    return $this->request('POST', '/orders/get', [
        'dateFrom' => $dateFrom,
        'statuses' => ['AWAITING_PACKAGING'],
    ])['orders'] ?? [];
}

public function shipOrder(string $orderId, string $trackingNumber, string $carrier): void
{
    $this->request('POST', "/orders/{$orderId}/ship", [
        'trackingNumber' => $trackingNumber,
        'deliveryService' => $carrier,
    ]);
}

Чому важливий моніторинг помилок API?

СберМегаМаркет повертає коди помилок у тілі відповіді. Якщо їх не обробляти, складська логіка зламається. Ми логуємо кожну відповідь, а при помилках 429 (Too Many Requests) використовуємо повтор з експоненційною затримкою. Це гарантує, що жодне замовлення не загубиться.

Згідно з офіційною документацією СберМегаМаркет, максимальна кількість товарів в одному запиті — 500.

Порівняння методів інтеграції

Після впровадження автоматизації кількість скасованих замовлень скорочується на 90%.

Процес впровадження та терміни

Етапи роботи

1. Аналітика — вивчаємо ваш каталог, виявляємо нестандартні поля та особливості бізнес-логіки.
2. Проєктування — складаємо мапінг полів та вибираємо метод завантаження (YML або REST).
3. Реалізація — пишемо модуль інтеграції з тестовим стендом.
4. Тестування — перевіряємо на 10 випадкових товарах, потім на повному асортименті.
5. Деплой — переносимо на бойовий сервер, налаштовуємо моніторинг.
6. Навчання — 1 година з вашими менеджерами: як керувати доступом та читати звіти.

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

Базовий YML-фід — 2–3 дні. Повна REST-інтеграція — 6–10 робочих днів. Точна вартість залежить від кількості SKU та складності логіки, обговорюється індивідуально. Середня економія часу — від 200 годин ручної праці на місяць.

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

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

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

Ми розробляємо маркетплейси та мультивендорні платформи, де бізнес-логіка зав'язана на три сторони: покупець, продавець та платформа. Помилка в розрахунку комісії на 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+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.