Quickmock

Протестировать приём вебхуков

Ловить входящие вебхуки и смотреть их заголовки и тело в реальном времени.

Чтобы протестировать приёмник вебхуков, нужен публичный URL, до которого отправитель реально достучится, — а значит, localhost отпадает. Мок вебхук-эндпоинта даёт такой URL сразу: он принимает POST, отвечает подтверждением, которого ждёт провайдер, и записывает запрос целиком, так что вы видите заголовки и тело, которые отправитель действительно прислал, а не те, что описаны в документации.

Почему провайдер не может просто позвать localhost?

Вебхук — это сервер провайдера, который вызывает ваш. http://localhost:3000 означает «эта машина» и на их стороне тоже, поэтому их вызов вообще не покидает их сеть. Туннели решают это, выставляя наружу ваш ноутбук; мок-эндпоинт решает это, убирая ваш ноутбук из схемы совсем.

На раннем этапе разница существенная. Пока обработчика ещё нет, вам на самом деле нужно узнать, что именно шлёт провайдер: какие заголовки, какое тело, какой content type. Мок отвечает на этот вопрос за одну доставку, и обработчик вы пишете уже по записанному запросу, а не по примеру из документации.

Что эндпоинт должен ответить отправителю?

Почти все провайдеры считают успехом любой 2xx, а всё остальное — поводом повторить доставку. Значит, отвечать нужно быстро, статусом 200 и коротким телом. Stripe повторяет доставку сутками, если ответ не 2xx; GitHub фиксирует неудачу в журнале доставок. Медленный обработчик оба наказывают так же, как сломанный.

Некоторым провайдерам мало одного статуса. Events API у Slack не включит эндпоинт, пока тот не вернёт обратно значение challenge из проверочного запроса. Если ваш эндпоинт обязан отвечать чем-то, вычисленным из запроса, мокайте именно это эхо, а не фиксированное тело.

Как увидеть, что отправитель прислал на самом деле?

Откройте инспектор мока — там перечислена каждая доставка с методом, заголовками, телом и временем. Это как раз то, что иначе получить тяжело: заголовки подписи, точный content type и расхождение между тем, что провайдер документирует, и тем, что он передаёт.

Инициируйте настоящее событие из панели провайдера, а не отправляйте себе самописный POST. Payload, который вы придумали сами, подтверждает ваши догадки; payload, который прислал провайдер, их исправляет.

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

Что обычно идёт не так?

  • Тестируют выдуманным payload'ом. Это доказывает, что ваш парсер справляется с вашим же JSON, в чём никто и не сомневался.
  • Отвечают 200 до или после работы. Подтверждать надо быстро, а обрабатывать асинхронно: провайдеры отваливаются по таймауту задолго до того, как медленный обработчик закончит.
  • Игнорируют повторные доставки. Ретраи означают, что одно и то же событие придёт дважды. Обработчик обязан быть идемпотентным, а отправить одну и ту же доставку дважды — это и есть способ это доказать.
  • Думают, что мок проверяет подпись. Не проверяет. Проверка подписи — работа вашего обработчика, и тестировать её надо против настоящего отправителя.

Когда это нужно

Чтобы подключить чужой вебхук (Stripe, GitHub, платёжка), нужен URL, куда его направить — и способ увидеть, что именно он шлёт. Создай POST-мок, отдай его URL провайдеру и смотри каждый вызов в живом инспекторе: метод, заголовки, query, тело.

Создать мок

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "POST",
  "response_status": 200,
  "response_body": "{\"received\":true}"
}'

Вызвать

curl -X POST -H 'Content-Type: application/json' -d '{"event":"payment.succeeded"}' https://quickmock.dev/m/<slug>

Открой страницу мока и вставь его admin-токен, чтобы видеть метод, заголовки, query и тело входящих запросов в приватном живом инспекторе.

Что получите

{"received":true}

Частые вопросы

Можно ли протестировать вебхук, не выставляя наружу локальную машину?
Да, ради этого мок-приёмник и нужен. Провайдер зовёт публичный URL, который не является вашим ноутбуком, так что доставки можно ловить и читать без туннеля и без открытого порта.
Увижу ли я заголовки подписи, которые шлёт провайдер?
Да. Инспектор пишет заголовки каждой доставки, включая подписные заголовки провайдеров — Stripe-Signature, X-Hub-Signature-256 и подобные. Заголовки с учётными данными (Authorization, Cookie, X-Api-Key) сохраняются замаскированными, а из повторяющегося заголовка остаётся только первое значение. Проверка подписи по-прежнему задача вашего обработчика — мок принимает всё, что пришло.
Может ли эндпоинт ответить значением из самого запроса?
Да. Токены запроса позволяют вернуть в ответе часть входящего тела — именно этого требуют рукопожатия вроде url_verification у Slack, без которого эндпоинт не включится.

Собери свой

Создать мок

Готовые шаблоны для этого: Замокать вебхук Stripe, Замокать вебхук заказа Shopify, Замокать push-вебхук GitHub

Похожие гайды

← Все гайды

Обновлено: 2026-09-08