Ошибки¶
Страница для интегратора: что означает отказ, что с ним делать и куда идти, если непонятно.
Форма отказа¶
Любой отказ приходит одним и тем же телом:
{
"error": {
"type": "invalid_request_error",
"code": "template_not_active",
"message": "Шаблон 'otp-login' на модерации у оператора, отправка невозможна.",
"param": "template",
"doc_url": "https://docs.sms.termdev.ru/errors#template_not_active",
"request_id": "req_01J8Z3Q6N2K7V4M9X5T1B8C0DE"
}
}
Ветвиться следует по code, а не по HTTP-статусу и тем более не по тексту:
код стабилен, статус у разных причин совпадает, а текст мы вправе уточнить.
type— класс отказа.invalid_request_errorчинит клиент,authentication_errorиpermission_error— про ключ,rate_limit_error— про темп,api_error— про нас.param— какое поле запроса виновато, если виновато конкретное.request_id— идентификатор запроса:req_и 26 символов. Он есть в каждом ответе, включая успешный (заголовокRequest-Id), и это первое, что нужно приложить к вопросу о конкретном запросе. Присланный клиентомRequest-Idигнорируется — идентификатор всегда выдаёт хаб.retry_after— секунды до осмысленного повтора. Приходит там, где повтор вообще имеет смысл, и дублируется заголовкомRetry-After.
Что повторять¶
429— повторить не раньшеretry_after. Если отправка шла сIdempotency-Key, повторять следует с тем же ключом: отказ по темпу не приколачивается к ключу, и повтор пройдёт как первый запрос.409 idempotency_conflict— первый запрос с этим ключом ещё выполняется. Повторить послеretry_after. Если первый запрос завершился успехом или окончательным отказом (4xx, кроме429), повтор получит его сохранённый ответ; если первый кончился5xxили429, ключ освобождается и повтор выполняется заново.5xx— наша неисправность. Повторить с тем жеIdempotency-Key; ответы5xxк ключу не приколачиваются.422— запрос понятен, но невыполним. Повтор того же запроса даст тот же отказ: сначала исправить то, на что указываетcodeиparam.
Реестр кодов¶
Таблица генерируется из реестра в коде: расхождения между ней и поведением хаба быть не может.
Все страницы руководства — оглавление.
503 provider_unavailable и 500 internal_error разделены по тому, что делать
дальше. Первый означает «запрос не принят, сейчас не можем»: так отвечает приём,
когда недоступно наше хранилище или шина, — повтор безопасен, пауза до него в
retry_after. Неподтверждённая брокером публикация отвечает 503 только
одноразовому коду: код отзывается, и повтор с тем же Idempotency-Key и
client_ref примет его заново. Сервисное сообщение в той же ситуации получает
обычный 202 и остаётся принятым — его отправит сборщик через одну–три минуты;
повторять его не нужно. В пакете такой одноразовый код приходит элементом с
результатом rejected. Второй означает нашу
неисправность: повтор того же запроса сам по себе её не обойдёт, и правильный
шаг — сообщить нам request_id из ответа.
Часть кодов объявлена заранее и сейчас не выдаётся: consent_required и
marketing_window_violation относятся к классу marketing, который в MVP
выключен, а send_at_in_past и send_at_too_far — к отложенной отправке,
которой в MVP нет (любой send_at получает send_at_not_supported). Обработку
на них заводить можно, ждать — не стоит. См. Ограничения MVP.
Отдельно от кодов отказа существуют причины недоставки (reason_code): они
объясняют судьбу уже принятого сообщения, а не отказ в приёме. Пространства не
пересекаются — по одному значению всегда видно, о чём речь. Причины и что с
ними делать — на странице «Статусы и их проверка».