ВАШЕ СООБЩЕНИЕ ОБ ОШИБКЕ ЧИТАЕТ УСТАВШИЙ ЧЕЛОВЕК В ДВА ЧАСА НОЧИ

ВАШЕ СООБЩЕНИЕ ОБ ОШИБКЕ ЧИТАЕТ УСТАВШИЙ ЧЕЛОВЕК В ДВА ЧАСА НОЧИ

И если в ответ он видит сухое `invalid_request`, вы уже проиграли часть DX.

Для разработчика ошибка — это не «техническая деталь», а точка контакта с вашим продуктом. В ней должно быть сразу понятно:
- что именно сломалось;
- почему это произошло;
- как исправить;
- куда идти, если не помогло.

Хорошая ошибка экономит время, плохая — создает лишний тикет, лишнее письмо и лишнее раздражение. В итоге страдает не только API, но и доверие к команде 🧩

Полезный ориентир — писать ошибки по логике RFC 9457, но человеческим языком. Не просто код, а структура: тип проблемы, понятное сообщение, детали и действие дальше.

И да, предсказуемый, «скучный» API — это не скука. Это комплимент. Значит, его можно подключить ночью, без созвона и без гаданий.

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