**Ночь, релиз, API, и в ответ — `invalid_request`.**

**Ночь, релиз, API, и в ответ — `invalid_request`.**
Классика плохого DX: ошибка есть, смысла нет. Разработчик не понимает, что сломалось, где чинить и почему он вообще должен угадать вашу логику за 40 минут до падения продакшена.

Вот где обычно сливают онбординг:
- голые коды вместо нормального описания;
- нет контекста: какое поле битое, что ожидалось, что пришло;
- нет следующего шага — только тупик и тикет в поддержку.

Нормальный API должен быть предсказуемым и скучным. Да, это комплимент.
Ошибка должна отвечать на 3 вопроса: **что сломалось**, **почему**, **что делать дальше**. Иначе вы не строите продукт, а устраиваете квест для уставших людей в 2:00 ночи.

Практика простая: перепишите ошибки по человеческому стандарту, замерьте `time to first successful call` и уберите магию из ответов.
Чем меньше гаданий, тем меньше злых писем. Чем меньше сюрпризов, тем выше шанс, что ваш API не выкинут после первого фейла.