Для отладки вебхука нужен не «туннель в интернет», а воспроизводимый контур: публичный URL, лог входящего запроса, возможность переиграть payload и контроль над ответом хендлера. Иначе вы видите только симптом — «ничего не прилетает» — и теряете время на гадание.
ngrok годится для быстрого проброса локалки: поднял туннель, получил внешний адрес, смотришь в тело запроса. Но у такого подхода есть цена: URL меняется, сессии рвутся, а если webhook-провайдер не умеет нормально ретраить, тест превращается в лотерею. Сразу ставьте идемпотентный обработчик и храните event_id в БД или кеше.
Hookdeck и похожие прокси полезны там, где нужен буфер между внешним API и вашей машиной: логирование, повторная доставка, фильтрация, replay, маскирование секретов. Это уже не просто «перекинуть порт», а маленькая очередь перед хендлером. Для нестабильных интеграций это спасает: ловим payload, кладём в пайплайн, потом дергаем локальный сервис хоть десять раз.
Минимальный набор для локальной отладки:
— один стабильный публичный endpoint;
— лог raw body до парсинга JSON;
— проверка подписи до бизнес-логики;
— отдельный режим replay;
— таймауты и ретраи на стороне клиента.
Если нужен быстрый старт — берите туннель. Если важны повторяемость и разбор инцидентов — ставьте промежуточный webhook-proxy. Идемпотентность — это не роскошь, а база.
Автоматизация на вебхуках
@webhook_automation_hub_arb
Локальная отладка вебхуков без магии: как не ловить 5xx на ровном месте
Этот пост опубликован в Telegram-канале Автоматизация на вебхуках. Подписаться можно по ссылке: @webhook_automation_hub_arb.