error.code — именно на него опирайтесь в коде интеграции, а не на текст message.
Формат конверта
boolean
false для любой ошибки. Проверяйте это поле перед чтением data.string
Стабильный машинно-читаемый код. Ветвите логику обработки по нему.
string
Человекочитаемое пояснение. Текст может меняться между релизами — не парсите его.
object
Опциональный объект с контекстом. Например, для
STATUS_TRANSITION_NOT_ALLOWED —
{ entity, from, to }; для VALIDATION_FAILED — { errors: [...] }.string
Идентификатор трассировки. Присутствует, когда запрос дошёл до платформы. Указывайте его
при обращении в поддержку — по нему оператор найдёт запрос в логах.
HTTP-статус и код ошибки
HTTP-статус задаёт семейство ошибки, аerror.code уточняет причину. Базовый маппинг,
когда конкретный код не выставлен явно:
Справочник кодов
Ниже — полный каталог кодов, которые может вернуть Public API, сгруппированный по семейству.Аутентификация и подпись (400 / 401 / 403)
Идемпотентность и конфликты (409)
Не найдено (404)
Валидация входных данных (400 / 404 / 422)
Бизнес-лимиты: суммы, баланс, комиссии (409 / 422)
Политики выплат (400 / 422)
Платформа и доступность (429 / 503 / 5xx)
Обработка ошибок в коде
Ветвитесь поerror.code, а 5xx и 429 — повторяйте с экспоненциальным backoff.
Транзиентные коды (
INTERNAL_ERROR, DATABASE_ERROR, PROVIDER_UNAVAILABLE,
PROVIDER_DEGRADED, ALL_PROVIDERS_FAILED, RATE_LIMITED, MAINTENANCE_MODE) безопасно
повторять — особенно если вы прислали X-Idempotency-Key, повтор не создаст дубликат.
Клиентские коды (VALIDATION_FAILED, INVALID_*, DUPLICATE_ORDER_ID,
AMOUNT_*) повторять бессмысленно — сначала исправьте запрос.Частые вопросы
Почему всё время INVALID_SIGNATURE, хотя секрет верный?
Почему всё время INVALID_SIGNATURE, хотя секрет верный?
Подписывается сырое тело запроса — ровно те байты, что уходят на сервер. Если вы
сериализуете JSON один раз для подписи, а второй раз (с другими пробелами/порядком ключей)
для отправки — подпись не сойдётся. Сериализуйте один раз и подписывайте именно эту строку.
Подробнее — Аутентификация.
В чём разница между DUPLICATE_ORDER_ID и IDEMPOTENCY_CONFLICT?
В чём разница между DUPLICATE_ORDER_ID и IDEMPOTENCY_CONFLICT?
DUPLICATE_ORDER_ID — вы повторно использовали order_id, уже занятый другой заявкой
(строгий режим). IDEMPOTENCY_CONFLICT — вы прислали тот же X-Idempotency-Key, но с
другим телом запроса. Первое лечится новым order_id, второе — новым ключом либо повтором
ровно того же тела. См. Идемпотентность.Что делать при 5xx?
Что делать при 5xx?
Повторяйте с экспоненциальным backoff. Если вы прислали
X-Idempotency-Key, повтор не
создаст дубликат. Сохраните error.traceId — по нему оператор найдёт запрос в логах инстанса.Можно ли полагаться на текст error.message?
Можно ли полагаться на текст error.message?
Нет.
message предназначен для людей и может меняться. Ветвите логику только по
error.code — он стабилен.