Skip to main content

Implement webhooks as in Market App Desktop

Ideas

Add webhooks, similar to those in the Market App Desktop for developers, to avoid constantly polling the trade history and ensure timely responses to status changes. As a last resort, provide an API endpoint for the dashboard with counters, similar to what the client already has. This request will allow us to determine in advance whether there are any new events.

Posted by Анастасия ·
Status: Voting1 comment

Comments1

  • qulery

    •

    Apr 19

    Проблема более фундаментальная, чем может показаться, и значительно повышает порог входа для новых трейдеров.

    Текущие эндпоинты, такие как history, operation-history, items - это всё исторический технический долг, накопившийся по мере адаптации маркета под внешние изменения в Steam.

    Сейчас отсутствует единый стабильный канал для быстрого реагирования на продажи для разработчиков, а также для качественной актуализации статусов.

    Те, кто работают с большими объёмами, а также отслеживают начисления на баланс или другие коллизии, обычно реализуют собственную базу данных со всеми трейдами и актуализируют статусы для быстрого анализа и сбора статистики.

    Сейчас существует 2 socket-канала, которые могут публиковать информацию о событии успешной покупки/продажи: auth ws, который предоставляет API, и client ws - socket-соединение активной сессии сайта.

    Хотя эти каналы и предоставляют информацию, разработчики часто могут пропускать события продаж/покупок из-за использования прокси или фризов в сети. Большинство прокси-провайдеров ограничивают максимальное время соединения до 5 минут. Хотя реализация автоматического переподключения не является проблемой, именно в этот момент событие успешной покупки/продажи может быть потеряно.

    Также не существует единого эндпоинта, который мог бы одновременно предоставлять информацию как об истории покупок/продаж, так и о статусе сделки. Самое главное - не только узнать, что мы купили предмет, но и в правильный момент понять, что определённый аккаунт нужно вывести в polling для сканирования входящих сделок в Steam.

    Нельзя обойтись только эндпоинтом items, так как он не содержит сделок, которые завершились ошибкой. Однако для создания устойчивой системы мониторинга сделок необходимо знать о каждой сделке, даже ошибочной. Как вариант - использование эндпоинтов history / operation-history, которые предоставляют информацию о каждой сделке, однако не предоставляют критически важный статус сделки: “товар можно принять” или “ожидается получение товара покупателем”.

    Поэтому часто в рамках реализации автоматизированных систем просто невозможно считать ws источником истины, из-за чего приходится постоянно polling-ом запрашивать эндпоинт operation-history для сканирования новых сделок, и эндпоинт items - когда есть трейды с неконечным статусом.

    Если бы history / operation-history содержал статус сделки, это позволило бы избавиться от лишнего запроса к эндпоинту items.

    Лучшее, что можно было бы улучшить на сайте, чтобы полностью избавиться от зависимости от history / operation-history / items / trades - это внедрение webhooks, которые со стороны маркета гарантировали бы доставку сообщения до трейд-сервера в течении 5-10 минут.

    Необходима чёткая задокументированная декларация статусов сделок и общий контракт оффера и его статусов:

    • Предмет продан/куплен

    • Ожидание, когда продавец передаст товар

    • Ожидание, когда покупатель получит товар

    • Ошибка по causer Seller / Buyer

    • Успешная сделка с переходом в Trade Protection

    • Полное успешное завершение сделки через 7–8 дней

    • Оффер получил reverse по causer Seller / Buyer

    Достаточно следующих данных в событии:

    • Цена покупки

    • Цена, которую получит продавец

    • Валюта покупки

    • Название товара market_hash_name

    • asset_id

    • offer_id

    Опционально, если будет несложно добавить:

    • steam_trade_id - для активной сделки, которую должен принять покупатель

    • meta{}.seller_currency - Нативная валюта товара продавца (опционально)

    В случае, если реализация webhooks сейчас окажется слишком сложной для маркета, можно обойтись следующими минимальными изменениями:

    • Добавить статус сделки в рамках history / operation-history, чтобы избавиться от необходимости использовать items

    • Реализовать Dashboard в рамках API, аналог клиентского me.dashboard, который позволит идентифицировать изменения в счётчиках и не запрашивать history / operation-history постоянно, пока не будет реальных изменений.

    Однако, учитывая, что подобная практика уже используется в Desktop Market App, реализация гарантии доставки может быть хорошим решением.

    При консервативном опросе истории акаунта 1 раз на минуту, это экономия в ~120k / hour для 2k акаунтов.