Как остановить runtime UnifyPort и не дать автовосстановлению запустить его снова

Чтобы временно остановить подключение аккаунта обмена сообщениями UnifyPort, не удаляя аккаунт, отправьте {} в POST /v1/accounts/{account_id}/runtime/stop. Завершение подтверждает runtime_status: stopped; при stopping проверку нужно продолжить. До вызова сообщите вашим воркерам восстановления, что остановка запланирована. Иначе процесс, поддерживающий аккаунты онлайн, может запустить подключение снова.

Главное

• Остановка runtime сохраняет аккаунт и не равна удалению.
• Сначала сохраните намерение приостановить аккаунт в постоянном хранилище приложения.
• Наблюдаемый runtime_status и разрешение на восстановление — разные решения.
• Возобновление подключения не доказывает, что сообщения за период остановки восстановлены.

Правильное восстановление в неподходящий момент

Представим ситуацию: оператор останавливает аккаунт для обслуживания, воркер мониторинга видит stopped и вызывает start, поскольку должен поддерживать соединения онлайн. Это условный пример, а не описание клиентского инцидента. Оба запроса могут соответствовать API, но противоречить намерению оператора.

Решение — не новая авторизация, а общая для приложения проверка: должен ли аккаунт сейчас быть подключён? Руководство по восстановлению runtime описывает восстановление соединения, которое должно работать. Плановая остановка добавляет проверку разрешения перед этой логикой.

Это не новая настройка API. Документация жизненного цикла разделяет status аккаунта, состояние авторизации и runtime_status. Предлагаемая запись о паузе принадлежит вашему приложению. Она не является новым полем UnifyPort или обещанным результатом изменения status аккаунта.

Определите, что именно требуется остановить

Цель	Подходящий уровень управления
Приостановить запись в CRM или обработку ИИ, продолжая приём сообщений	Консьюмеры приложения
Остановить активное подключение, сохранив аккаунт	Stop runtime
Вывести ресурс аккаунта из эксплуатации	Отдельная процедура удаления

Если обслуживание касается только последующей обработки, используйте сравнение вариантов обслуживания webhook. Остановка соединения не является механизмом надёжной буферизации сообщений.

Руководство по удалению аккаунта нужно только при выводе ресурса из эксплуатации. Контракт runtime stop не обещает возврат средств, приостановку подписки, удаление исходного аккаунта платформы или стирание сохранённых сообщений.

Сначала сделайте намерение остановки доступным воркерам

Рекомендуемый порядок на стороне приложения:

1. Зафиксируйте workspace, account_id, канал, оператора и причину. Отдельно прочитайте аккаунт и состояние авторизации.
2. Сохраните решение о паузе для этого аккаунта в постоянном хранилище. Воркеры восстановления и запланированной отправки должны проверять его перед новыми запросами.
3. Согласуйте действия с уже работающими воркерами. Новый флаг не отменяет API-запрос, который уже отправлен. Нужны собственная координация по аккаунту и проверка выполняющихся операций.
4. Оставьте webhook-приёмник доступным для проверки и сохранения продолжающих поступать событий. Остановка runtime не означает гарантированного завершения всех доставок webhook.
5. Отправьте один проверенный запрос остановки и изучите результат.

Ниже — псевдокод приложения, а не синтаксис SDK или новый endpoint:

перед автоматическим start или reconnect:
    прочитать текущее намерение работы аккаунта из локального хранилища
    если оператор назначил паузу:
        не отправлять запрос восстановления
    иначе:
        проверить авторизацию и runtime
        выбрать документированное действие восстановления

Эту проверку должны проходить все пути восстановления, включая отложенные задания и ручные кнопки. Координируйте паузу и возобновление, чтобы старое задание запуска не стало допустимым только из-за более позднего изменения в интерфейсе.

Остановите один раз и проверьте фактический результат

Справочник Stop runtime требует пустой JSON-объект. Пример ниже здесь не выполнялся. Заполните переменные из проверенного выбора аккаунта на backend и защищённой конфигурации API-ключа:

curl -X POST \
  "https://api.unifyport.ai/v1/accounts/${UNIFYPORT_ACCOUNT_ID}/runtime/stop" \
  -H "X-Api-Key: ${UNIFYPORT_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{}'

Храните ключ на сервере. Сохраняйте HTTP-статус и доступную диагностику запроса, но не секреты.

Наблюдение	Значение и следующий шаг
runtime_status: stopped	Остановка runtime завершена; локальное решение о паузе остаётся
runtime_status: stopping	Переход ещё выполняется; проверьте состояние снова
Тайм-аут или нечитаемый ответ	Результат неизвестен; прочитайте состояние до следующего изменения
При локальной паузе runtime стал running	Найдите конкурирующие вызовы start или reconnect; не объявляйте подготовку к обслуживанию завершённой

Для сверки используйте Get account или Refresh runtime state. Refresh синхронизирует состояние, а не запрашивает перезапуск. Задайте ограниченную политику проверок и эскалации в приложении, не придумывая гарантированный срок завершения.

Не ждите события account.stopped, отсутствующего в публичном каталоге. Документация жизненного цикла не гарантирует account.status.updated для каждого запрошенного перехода. Отсутствие новых сообщений тоже не доказывает остановку.

Возобновление — отдельный подтверждённый переход

Не разрешайте исходящие задания, пока проверяете текущую авторизацию сохранённого аккаунта. Если нужно действие пользователя, продолжите соответствующий процесс авторизации. Успешная авторизация обычно автоматически запускает runtime, поэтому не начинайте её во время паузы без такого намерения.

Если авторизация действительна, а runtime остановлен, используйте Start runtime. Согласуйте явное возобновление с локальными ограничениями и проверьте переход к фактическому running. Ответ starting ещё не означает завершение.

Перед выпуском накопленных заданий убедитесь, что каждое остаётся актуальным. Отправьте контролируемое тестовое сообщение, проследите проверку подписи и сохранение нового события. После этого включите нужные консьюмеры и политику автоматического восстановления.

Неофициальный интерфейс UnifyPort не гарантирует повторную доставку пропущенных payload и не предоставляет универсальный REST API чтения истории сообщений. Зафиксируйте период остановки как возможный пробел в сборе данных. Успешный новый тест подтверждает работоспособность возобновлённого пути, а не восстановление этого пробела.

FAQ

Stop удаляет аккаунт?

Нет. Документированное действие останавливает runtime, сохраняя аккаунт. Повторный запуск — отдельная операция.

Нужно ли запускать каждый аккаунт в состоянии stopped?

Нет. Сначала проверьте, должно ли приложение сейчас поддерживать его онлайн. Состояние runtime не выражает намерение оператора.

Успешная остановка отменяет ответы в очереди и доставку webhook?

Не следует этого предполагать. Задания приложения управляются отдельно; публичный контракт не обещает отмену уже отправленной работы или завершение очереди webhook.

Остановка приостанавливает оплату?

Контракт runtime stop этого не обещает. Состояние подключения не является доказательством финансового изменения.

Следующий шаг и источники

Реализуйте локальную проверку разрешения на восстановление вместе со Stop runtime. Проверьте конкурирующий воркер, выполняющийся start, потерю ответа stop, stopping, явное возобновление и устаревший ответ в очереди. Это предлагаемые проверки, а не уже полученные результаты.

Документация проверена 2026-11-04:

• UnifyPort: Stop runtime
• UnifyPort: Жизненный цикл аккаунта
• UnifyPort: Доставка webhook и ограничения восстановления