Интеграция сайта с CRM перестаёт работать не только из-за ошибки в коде. Частая причина проще: токен API удалили, заменили или передали подрядчику без понятного учёта. В статье разберём, чем долгосрочный токен отличается от access_token и refresh_token, где его хранить, что проверить перед заменой и как восстановить обмен данными между сайтом, формами и CRM без хаотичных правок.
Почему интеграция сайта с CRM внезапно перестаёт передавать заявки?
Сайт может продолжать открываться, формы будут выглядеть исправно, а новая заявка не попадёт в CRM. Посетитель увидит сообщение об успешной отправке, но менеджер не найдёт карточку клиента. Такая ошибка особенно неприятна тем, что её легко заметить только после обращения клиента по телефону.
Одна из причин связана с API-токеном. Внешний сервис использует его как пропуск к аккаунту CRM. Если токен отозвали, изменили настройки доступа или заменили интеграцию, запросы сайта начинают возвращать ошибку. Иногда проблема появляется после передачи проекта другой студии: прежний подрядчик создал подключение на своём аккаунте и не оставил владельцу понятных инструкций.
Перед поиском сложной технической причины проверьте четыре вещи:
- создаётся ли заявка в CRM при тестовой отправке формы;
- появляется ли ошибка в журнале интеграции или на стороне сервера;
- какой токен использует сайт сейчас;
- кому принадлежит аккаунт, из которого выпустили токен.
Если сайт передаёт обращения в amoCRM, полезно отдельно проверить, не перепутал ли разработчик долгосрочный токен с данными OAuth-приложения. Такая путаница встречается в проектах, где интеграцию собирали по частям и не описали её устройство.
Чем отличаются долгосрочный токен, access_token и refresh_token?
Названия похожи, поэтому их часто смешивают. На практике это разные элементы авторизации, и замена одного значения другим ломает подключение.
| Элемент | Для чего нужен | Что проверить владельцу бизнеса |
|---|---|---|
| Долгосрочный токен API | Передаёт внешнему сервису доступ к аккаунту CRM через значение, которое указывают в настройках интеграции | Где он создан, кто имеет к нему доступ и какие сервисы его используют |
| access_token | Используется в OAuth-сценарии для обращения к API | Не заменяет автоматически долгосрочный токен в уже настроенной интеграции |
| refresh_token | Помогает получить новый access_token в OAuth-схеме | Не следует вставлять его в поле, где интеграция ожидает другой тип ключа |
В материалах об API amoCRM отдельно подчёркивается: access_token, refresh_token и долгосрочный токен получают и обновляют по разным сценариям (источник: «Долгосрочный токен API amoCRM: как получить и обновить»). Поэтому перед исправлением нужно выяснить, какую схему применили именно в вашем проекте.
Простой способ разобраться, что происходит внутри: попросить подрядчика назвать точное место хранения ключа, способ авторизации и действие, после которого токен перестанет работать. Ответ в духе «он где-то в настройках» не заменяет техническое описание. Для малого бизнеса достаточно одной страницы в рабочем документе: сервис, назначение, владелец, дата создания, место хранения и порядок замены.
Как безопасно заменить токен API, если доступ уже потерян?
Сначала создайте новый ключ, затем внесите его в интеграцию и только после проверки отключайте старый. Такой порядок оставляет возможность быстро вернуть рабочую конфигурацию, если в новом значении ошибка.
- Определите все точки, где используется старый токен: сайт, серверный сценарий, CRM-робот или внешний сервис.
- Создайте новый токен в аккаунте владельца CRM, а не в личном кабинете случайного подрядчика.
- Передайте значение разработчику по защищённому каналу. Не вставляйте его в общий чат, задачу с открытым доступом или публичный документ.
- Замените ключ в конфигурации интеграции и сохраните резервную копию прежних настроек.
- Отправьте несколько тестовых обращений с сайта и проверьте создание сделки, контакта или задачи в CRM.
- Посмотрите, не появились ли дубли, потерянные поля и неправильное распределение заявок по менеджерам.
Тестировать нужно по полному маршруту. Форма должна отправить данные, сервер должен принять запрос, CRM должна создать нужную сущность, а менеджер должен увидеть уведомление. Если проверить только наличие ответа «форма отправлена», сбой на последнем этапе останется незаметным.
Для сайта с несколькими формами составьте короткую таблицу проверки: страница, тип обращения, ответственный менеджер, результат в CRM. Такой список помогает не забыть форму расчёта, заявку на консультацию или отдельный сценарий для мобильной версии.
Как передать интеграцию новому подрядчику без потери контроля?
Передача сайта начинается с инвентаризации. Владелец бизнеса должен знать, какие сервисы связаны с CRM и кто управляет доступами. Это касается не только токена: в цепочке могут участвовать формы сайта, телефония, аналитика, сценарии уведомлений и автоматические задачи.
Попросите подготовить описание в понятном формате:
- какие данные сайт отправляет в CRM;
- какая сущность создаётся после заявки;
- какие поля обязательны;
- как система выбирает ответственного менеджера;
- куда записываются ошибки;
- как выполнить тестовую отправку;
- что делать при замене токена.
Отдельно зафиксируйте владельца аккаунта CRM. Если интеграция оформлена на адрес подрядчика, компания зависит от его доступности. После завершения работ доступы и инструкции должны находиться у бизнеса, а не только в переписке с разработчиком.
Когда сайт связан с телефонией, полезно описать и телефонный контур: какие звонки передаются в CRM, где сохраняется источник обращения и как менеджер видит историю диалога. Для настройки рабочих процессов можно сопоставить такой подход с рекомендациями по настройке Битрикс24 для колл-центра малого бизнеса. Даже если в компании один менеджер, схема помогает понять, где заканчивается сайт и начинается обработка обращения.
Какие ошибки чаще всего ломают API-интеграцию?
Проблема с токеном обычно возникает не в момент его создания, а позже, когда меняется сайт, CRM или состав подрядчиков. Ниже перечислены ситуации, которые стоит проверить до обращения к разработчику.
- Ключ вставили не в тот проект. На сервере может работать другая версия конфигурации, чем та, которую редактировали.
- Перепутали тип токена. Значение для OAuth вставили в поле долгосрочного токена или наоборот.
- Старый ключ удалили слишком рано. После этого нельзя быстро сравнить рабочую и новую конфигурацию.
- Проверили только форму. Страница показала успешную отправку, но CRM не создала карточку.
- Не учли тестовый и рабочий контур. Разработчик проверил заявку на копии сайта, а пользователи отправляют её с основной версии.
- Нет журнала ошибок. Без записи времени, запроса и ответа API поиск причины превращается в догадки.
Если интеграция передаёт заявки в amoCRM, отдельный документ с описанием токена и порядка его обновления стоит включить в передачу проекта. Если сайт работает на другом стеке, принцип тот же: ключи должны иметь владельца, понятное назначение и проверяемый сценарий замены.
3 шага, которые можно сделать на этой неделе:
- Попросить разработчика перечислить все интеграции сайта с CRM и указать, какой тип авторизации использует каждая.
- Отправить тестовую заявку с компьютера и телефона, затем проверить её путь до карточки в CRM.
- Сохранить инструкцию по замене токена в рабочем доступе компании и назначить сотрудника, который отвечает за проверку интеграции.
