Как принять webhook Anthropic API: проверка подписи и защита от дублей

1. Отдельный тестовый проект или среду, где ошибка не затронет клиентов.
2. Один обезличенный пример данных и ожидаемый результат в двух-трёх предложениях.
3. Журнал: время, версия модели или интеграции, идентификатор запроса, итоговый статус.
4. Правило остановки: какие ответы нельзя публиковать или выполнять автоматически.

Не отправляйте в запросы ключи доступа, полные договоры с персональными данными или внутренние инструкции, если у вас нет разрешения и понятной политики обработки. Чем точнее входные данные, тем легче отличить полезный ответ от правдоподобного, но неверного.

Порядок работы

Примите запрос по HTTPS, сохраните сырое тело, проверьте подпись по инструкции Anthropic и верните быстрый успешный ответ только после базовой валидации. Тяжёлую работу перенесите в очередь. Идентификатор события сохраняйте до запуска обработчика: это защитит от повторной доставки.

После каждого шага сохраняйте минимально необходимый след: идентификатор операции, версию входных данных и причину решения. Не полагайтесь на текстовое «готово» от модели как на техническое подтверждение. Если интеграция сообщает об ошибке, сначала разберите статус и документацию, а уже затем меняйте промпт или код.

Готовый шаблон запроса

Сгенерируй контракт очереди для webhook-события: event_id, event_type, received_at, signature_verified, processing_state. Добавь правила дедупликации и ручной повтор только для задач со статусом failed.

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

Пример и проверка результата

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

Проверяйте результат по пяти пунктам:

1. Использованы ли только переданные и явно разрешённые данные.
2. Выполнен ли обещанный формат: поля, типы, длина, язык.
3. Отмечены ли пропуски, неоднозначности и рискованные действия.
4. Не изменился ли бизнес-смысл при сокращении или классификации.
5. Можно ли повторить запуск и объяснить, почему система приняла решение.

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

Типичные ошибки