API для продавца GGsel — варианты автоматизации
Ручное ведение витрины на GGsel упирается в потолок примерно на сотне SKU: остатки расходятся, цены устаревают, а выдача кода в три часа ночи никого не ждёт. Автоматизация здесь — не про красоту архитектуры, а про то, чтобы не платить деньгами и рейтингом за каждую человеческую задержку. Разберём, что реально автоматизируется, где живёт программный слой, какую архитектуру выбрать и какие отказы обязательно нужно спроектировать заранее.
Материал технический, но без предварительного опыта интеграций читается нормально. Если вы совсем в начале, посмотрите квикстарт по API.
Где на самом деле живёт API
GGsel как витрина опирается на инфраструктуру Digiseller — именно этот слой отвечает за приём оплаты, карточки товаров и автоматическую выдачу цифровых товаров. Практически это значит, что программные возможности продавца определяются возможностями этого слоя, а не «API GGsel» как отдельного продукта.
Отсюда первое правило: не проектируйте интеграцию по статьям и форумам. Состав методов, схема авторизации и лимиты запросов меняются. Актуальную документацию сверяйте на стороне платформы перед началом разработки и после каждого крупного релиза с их стороны.
Второе правило: начинайте с одного SKU. Полный цикл — заказ, выдача, статус, спорная ситуация — на одной позиции покажет вам все узкие места дешевле, чем миграция каталога из тысячи товаров.
Что стоит автоматизировать
Синхронизация остатков
Самая доходная автоматизация. Продажа товара, которого нет, — это спор, возврат и удар по рейтингу. Логика простая: остаток у поставщика меняется, ваш мидлвар обновляет доступность на площадке. Практика:
- Снимайте товар с продажи заранее, а не в момент нуля — заложите буфер.
- Разделяйте «нет в наличии» и «сбой связи». При таймауте поставщика лучше временно скрыть товар, чем продать неизвестно что.
- Логируйте каждое изменение — при разборе спора вам понадобится история.
Синхронизация цен
Закупочная цена меняется, розничная должна следовать за ней. Автоматика считает цену по формуле от закупки с учётом комиссии площадки, эквайринга и вывода средств — конкретные ставки берите из актуальных тарифов площадки, они меняются и их нельзя зашивать в код константой. Обязательно ставьте пол по марже: если расчётная цена уходит ниже минимальной рентабельности, товар снимается, а не продаётся в убыток. Методику расчёта смотрите в юнит-экономике реселлера.
Автовыдача кодов
Два подхода:
| Подход | Как работает | Плюс | Минус |
|---|---|---|---|
| Загруженный пул | Коды заранее залиты в карточку | Просто, не зависит от вашего сервиса | Ручное пополнение, риск опустошения |
| Внешняя выдача | Код запрашивается у вашего мидлвара при оплате | Один запас на все площадки | Требует высокой доступности сервиса |
На практике часто работает гибрид: небольшой буфер в пуле как страховка плюс внешняя выдача как основной путь. Общие принципы автоотгрузки разобраны в материале про автоматизацию выдачи цифровых кодов.
Статусы заказов
Оплата, выдача, спор, возврат — каждое событие должно попадать в вашу систему без ручного просмотра кабинета. Это база и для поддержки, и для сверки денег.
Архитектура: поставщик, мидлвар, площадка
Единственная рабочая схема выглядит так:
API поставщика → ваш мидлвар → площадка
Мидлвар — это ваш сервис, который держит нормализованный каталог, соответствие SKU поставщика и карточек площадки, правила ценообразования, журнал заказов и очередь событий.
Почему нельзя связать поставщика с площадкой напрямую:
- Нет единого журнала. При споре вы не докажете, какой код был выдан по какому заказу.
- Нет правил цены. Наценка, пол по марже и округление живут где-то посередине.
- Нет мультиплощадочности. Вторая витрина потребует ещё одной такой же связки.
- Нет контроля отказов. Ретраи, идемпотентность и деградация реализуются только у вас.
Если у вас несколько источников товара, добавляется маршрутизация — какой поставщик обслуживает конкретный SKU при заказе. Это отдельная тема, разобранная в маршрутизации мультисорсинга.
Идемпотентность: обязательный минимум
Сеть теряет ответы, площадки и поставщики делают ретраи. Без защиты повторный запрос на выдачу спишет второй код: покупатель получит один, а вы заплатите за два.
Рабочий контракт:
- Каждому заказу площадки соответствует стабильный ключ идемпотентности в вашей системе.
- Все исходящие запросы к поставщику несут этот ключ.
- Мидлвар сохраняет результат выдачи и на повтор возвращает тот же код, не обращаясь к поставщику снова.
- Ключ живёт достаточно долго, чтобы пережить любой разумный ретрай.
Тонкости и типовые ошибки — в разборе ключей идемпотентности.
Вебхуки: как не терять события
Правила простые и почти всегда нарушаются:
- Проверяйте подпись до любой обработки.
- Отвечайте быстро — приняли, положили в очередь, вернули успешный код. Синхронная бизнес-логика внутри обработчика даёт таймауты и лавину ретраев.
- Считайте доставку неупорядоченной и не гарантированной. Храните идентификатор события, отбрасывайте дубли, не полагайтесь на порядок.
- Держите сверку по API как страховку: периодический опрос статусов ловит то, что потерялось.
Подробный разбор — в интеграции вебхуков.
Режимы отказа, которые надо спроектировать
| Отказ | Что происходит | Как смягчить |
|---|---|---|
| Стокаут поставщика | Заказ оплачен, кода нет | Резервный источник, автоснятие с продажи, готовый шаблон ответа покупателю |
| Таймаут выдачи | Непонятно, списан код или нет | Идемпотентный повтор, затем сверка по ключу |
| Дубль вебхука | Заказ обрабатывается дважды | Дедупликация по идентификатору события |
| Рассинхрон цен | Продажа ниже себестоимости | Пол по марже и автоснятие позиции |
| Отзыв кода | Спор после доставки | Журнал выдачи, обращение к поставщику по гарантии |
Ни один из этих сценариев не экзотика — все они случаются регулярно, и разница между спокойным и болезненным бизнесом в том, написан ли обработчик заранее. Про восстановление после стокаута отдельно — в материале supplier stockout recovery.
Откуда брать товарный поток
Автоматизация имеет смысл только поверх поставщика с предсказуемым программным интерфейсом. FoxReload даёт именно такой контур: 900+ SKU по играм, гифт-картам, пополнениям, eSIM и софту, единый REST API с автоотгрузкой и мультирегиональные позиции — то есть один источник, к которому подключается ваш мидлвар, а не десяток ручных каналов. Как выбирать источник и что требовать письменно — в материале где продавцы GGsel берут игровые ключи.
И повторим главное: методы, лимиты и требования платформы меняются. Перед разработкой сверяйте актуальную документацию Digiseller и правила GGsel, а не переносите старую интеграцию без проверки.