Ошибки API amoCRM: 401, 403, 429 и проблемы OAuth
Разбор ошибок API amoCRM — 401 Unauthorized, 403 Forbidden, 429 Too Many Requests и сбои OAuth. Что проверить самому и когда нужна диагностика от 5 000 ₽.
Если интеграция «вчера работала», а сегодня сыпет 401, 403 или 429, проблема почти никогда не в «сломанном amoCRM целиком». Это ответ API на конкретный запрос: нет авторизации, нет прав или превышен лимит.
Статья для тех, кто чинит связку сам или хочет понимать смету подрядчика. Платный разбор: исправление ошибок amoCRM.
Содержание
- 401 Unauthorized
- 403 Forbidden
- 429 Too Many Requests
- OAuth: типичные поломки
- Мини-чеклист
- Пример осторожного retry
401 Unauthorized
Смысл: запрос без валидного доступа.
Частые причины:
- истёк access token, refresh не отработал;
- интеграцию отключили в кабинете;
- подставили ключ от другого аккаунта / субдомена;
- часы сервера сильно «уехали» (реже, но бывает).
Что сделать: обновить токен по refresh; если refresh тоже 401 — пройти OAuth заново; проверить base domain аккаунта.
403 Forbidden
Смысл: вы «кто-то», но на это действие прав нет.
Частые причины:
- узкие scopes приложения;
- роль пользователя интеграции без нужных сущностей;
- попытка писать в воронку/поле вне доступа;
- IP / ограничения на стороне вашего шлюза (реже путают с 403 CRM).
Что сделать: сравнить scopes с документацией нужных методов; выдать отдельную учётку с явными правами; не использовать личный админ-пароль в cron.
429 Too Many Requests
Смысл: слишком частые запросы. Ориентир вендора для многих интеграций — порядка 7 запросов в секунду на интеграцию (уточняйте актуальный лимит в документации amoCRM на момент работ).
Типичные антипаттерны:
- опрос API в тупом цикле без backoff;
- N+1: отдельный запрос на каждую сделку в цикле;
- несколько копий воркера с одним client_id;
- ретраи без jitter («все ретраят в одну секунду»).
Что сделать:
- Снизить частоту, включить очередь.
- Батчить чтения/записи, где API позволяет.
- Кэшировать справочники (пользователи, воронки).
- При устойчивом 429 на легитимной нагрузке — обсуждать лимиты с вендором после оптимизации своего кода.
OAuth: типичные поломки
| Симптом | Куда смотреть |
|---|---|
| Redirect mismatch | Точный redirect_uri в кабинете интеграции |
| Refresh перестал работать | Хранение refresh, ротация, повторный authorize |
| Виджет жив, API мёртв | Backend не обновил токен |
| «Работает у разработчика» | Staging client_id ≠ prod |
Не храните токены в фронтенде виджета. Не коммитьте секреты в git.
Мини-чеклист перед эскалацией
- Полный URL метода и HTTP-код (не скрин «ошибка»).
- Тело ответа (без секретов в тикете публично).
- Время первой ошибки и последний успешный запрос.
- Менялись ли пароли, виджеты, домен, подрядчик.
- Частота запросов (RPS) за последние 5–15 минут.
Смежные разборы: не работает интеграция, не приходят заявки.
Пример осторожного retry
Псевдокод — идея, не копипаста «в прод без очереди»:
attempt = 0
while attempt < 5:
response = call_api()
if response.status != 429:
return response
sleep(min(60, 2 ** attempt) + random_jitter())
attempt += 1
escalate_or_queue()При 401 — не крутить retry бесконечно: сначала refresh/OAuth.
Когда звать нас
- Нет своего backend-разработчика.
- 429 после «оптимизации», которую делал прошлый подрядчик.
- Нужен абонемент с мониторингом токенов и лимитов.
Диагностика одного симптома — от 5 000 ₽ (до 60 минут). Исправление — от 10 000 ₽.