Новый паттерн в DX для API: ошибка должна не “ломать”, а вести до фикса.

Если разработчик в 2 ночи ловит голое `invalid_request`, он не ищет причину — он уходит в гадание. А это уже лишние минуты до первого успешного вызова, сорванный онбординг и минус к доверию к продукту.

Что стоит зашить в ответы на ошибки:
- что именно сломалось: поле, формат, лимит, auth;
- почему это случилось;
- как исправить: пример, подсказка, ссылка на next step;
- машинно-читаемый код + человеческое описание.

Хороший API — это скучный API. Предсказуемый, без сюрпризов, с одинаковой логикой на всех ошибках. Для команды это не “красота”, а меньше тикетов в саппорт, быстрее интеграция и выше шанс, что API реально дойдет до продакшена ⚙️

Практический ход: переписать ошибки по схеме “что не так / почему / что делать” и проверить все ключевые сценарии — от 400 до rate limit. Там часто прячется самый дешевый рост.