Подпись webhook и окно replay: идемпотентность, чтобы 02:00 было скучным

Неподписанные callback — не события. Это неаутентифицированный HTTP, который случайно похож на ваш payload. Команды, которые «сначала примем, подпись потом», узнают цену в 02:00: повторный DLR, удвоенный STOP или второй debit кошелька, который финансы не размотают. Prepaid messaging делает сбой видимым в деньгах. Скучные привычки: проверка подписи на каждом запросе, ограниченное окно replay и ключи идемпотентности, которые финансы читают рядом со строкой ledger.

IOSOR ожидает аудируемые B2B-интеграции: подписанные webhook, ротируемые секреты, client-safe ошибки без чужих брендов. Около USD 1 000+ месячного platform usage correlation ID и evidence replay становятся материалом коммерческого review — не только инженерной гигиеной. Держите рядом вебхуки и ключи на запуске и вебхуки, которые переживают запуск.

Неподписанные callback — не события

Проверяйте подпись до разбора бизнес-полей. Отклоняйте отсутствующие, протухшие или несовпавшие подписи client-safe ошибкой — не обрабатывайте «всё равно, это пилот». Staging-consumer, который пропускает verification, учит production пропускать её. Каталог live для messaging не делает ваш webhook URL публичной свалкой. Если не можете доказать, кто подписал тело, у вас нет события — есть поддельный запрос.

Окна replay и почему случается 02:00

At-least-once доставка ретраит по timeout, 5xx и неоднозначной потере сети. Поздний retry в 02:00 — норма. Окно replay ограничивает, как долго подписанный payload ещё приемлем: слишком широкое — атакующий повторит старый STOP; слишком узкое — легитимный retry выглядит подделкой. Логируйте отказы окна отдельно от провалов подписи. См. повторы входящего вебхука. Отвечайте быстро, persist сначала, обрабатывайте async — handler, который трогает CRM до ACK, сам производит дубликаты.

Идемпотентность, которую финансы могут прочитать

Один и тот же event ID должен давать одно конечное состояние. Берите platform event/message ID — никогда не изобретайте ключ из timestamp плюс body. На известный ID возвращайте success без повторного debit. Исходящие send требуют той же дисциплины — идемпотентность, retry и деньги. Финансы должны объяснить каждую prepaid-строку против status event. Если timeout вызывает client retry storm, ledger покажет ущерб первым. Каталог in setup — не отмазка пропустить идемпотентность «до Live».

Ротация подписи без хаоса dual-accept

Ротируйте секреты без окна, где старая и новая подписи принимаются вечно. Спланируйте overlap, затем cut. Никогда не вставляйте production-секрет в тикет поддержки. Разведите sandbox и production consumers. Dead-letter с инструментом replay, чтобы ops мог повторно прогнать failed consumer без второго debit. Ведите correlation ID от send до строки ledger, чтобы 02:00 был runbook, а не археология.

Красные флаги

• Handler принимает неподписанные тела «пока что»
• Нет окна replay или окно измеряется неделями
• Перезапись статуса без сравнения timestamp
• Side effects в CRM/email до ACK
• Общий production-секрет в чате
• Дубли event ID за месяц, и никто не смотрит
• Client-facing ошибки с сырыми upstream-кодами

Начните с IOSOR

Откройте раздел параметров вебхуков в консоли IOSOR и настройте секретный ключ для проверки подписи входящих DLR. Установите допустимое окно повтора (replay window) не более пяти минут, чтобы автоматически отсекать устаревшие повторные вызовы. Убедитесь, что ваш шлюз сохраняет event ID в базе данных и возвращает 200 OK без повторного выполнения операций при дублирующихся событиях.

Итог IOSOR

Эта статья доказала, что корректная обработка вебхуков делает ночную повторную доставку событий обычным техническим эпизодом, а не аварией.