Отладка UnifyPort webhook через webhook.site
Когда вы подключаете новую интеграцию UnifyPort, первый вопрос обычно не «правильна ли логика моего обработчика?» — а «вообще что-нибудь до меня доходит?». webhook.site — самый быстрый способ это выяснить.
Что он на самом деле делает
webhook.site выдаёт одноразовый HTTPS URL в момент открытия. Любой запрос к этому URL — от curl-однострочника до боевого webhook — появляется на dashboard со всеми headers, сырым body, query string и таймингом. Без регистрации и установки. На бесплатном тарифе URL живёт неделю, на платном — дольше.
Когда его звать в интеграции UnifyPort
Честный ответ: всякий раз, когда подозреваете, что проблема может быть на нашей стороне, а не на вашей. Конкретно — три типичных момента:
- 1. Первичная проверка связности. Пока ваш реальный обработчик ещё не готов, направьте webhook устройства на URL webhook.site и пошлите тестовое сообщение. Если событие пришло — связность, привязка аккаунта и сессия провайдера здоровы.
- 2. Сравнение пропавшего события. Когда обработчик не видит ожидаемое событие (скажем, Telegram
message.received), временно добавьте второй target на webhook.site. Если там пришло, а у вас нет — баг в вашем коде; если ни там, ни там — открывайте тикет с delivery id. - 3. Осмотр полей, о которых вы забыли. Dashboard показывает полный нормализованный JSON, который мы отправляем — включая
data.attendees,data.conversation.titleи другие необязательные поля, которые не всегда присутствуют. Быстрее, чем перечитывать документацию.
Найти X-Device-Signature
Если на target настроен signing secret, каждое сообщение несёт три кастомных header:
Все три видны на панели Headers webhook.site. Чтобы убедиться в корректности подписи без написания кода, скопируйте timestamp и raw body и прогоните через наш гайд по CyberChef с вашим секретом — результирующий hex должен совпасть с header байт-в-байт.
Когда не стоит использовать
Всё, что хоть немного напоминает боевой трафик: реальные сообщения клиентов, реально используемые signing secret, PII, которая не должна оседать на чужом сервере. URL webhook.site предсказуемы и публичны — считайте, что всё, что вы туда вкинули, можно прочитать. Для долгой отладки на реальном аккаунте подключайте smee.io или self-hosted bin.
Альтернативы, которые нам тоже нравятся
- Pipedream RequestBin — удобнее, когда трафик надо наблюдать часами.
- smee.io — пересылает на localhost, а не просто захватывает; лучше для локального цикла разработки.
- ngrok — полноценный локальный туннель со встроенным инспектором на
127.0.0.1:4040. Это то, что мы открываем чаще всего во время реальной разработки.
Подключение к UnifyPort
Зарегистрируйте URL webhook.site через POST /v1/webhook-endpoints — задайте url на ваш bin и используйте subscribed_events: ["*"], чтобы ловить всё. Не передавайте signing_secret, пока не готовы проверять подпись; полная схема запроса — в документации.