Сброс и готовность порта

Создание порта и сброс IP запускают работу, которая может продолжаться после ответа API. Ориентируйтесь на наблюдаемое состояние, а не на фиксированную паузу.

Какой идентификатор передавать

В публичных маршрутах портов передавайте значение Port.port как {id}. Например, порт с "port": "10000" читается через GET /ports/10000 и сбрасывается через POST /ports/10000/reset.

Внутренние ObjectID и идентификаторы услуг не являются идентификаторами публичных маршрутов. resetToken используется только в GET /tokens/{token} и не заменяет bearer-авторизацию.

Жизненный цикл ручного сброса

Для каждого намеренного сброса отправляйте новый UUID-ключ идемпотентности:

curl -i -X POST "https://api.ltesocks.io/v2/ports/10000/reset" \
  -H "Authorization: Bearer ${LTESOCKS_API_TOKEN}" \
  -H "Idempotency-Key: 7c838e2d-7d52-42e7-aed1-528829cbd514"

Официальный SDK

const port = await client.ports.reset({
  id: '10000',
  idempotencyKey: '7c838e2d-7d52-42e7-aed1-528829cbd514',
});

from uuid import UUID

port = client.ports.reset(
    "10000",
    idempotency_key=UUID("7c838e2d-7d52-42e7-aed1-528829cbd514"),
)

<?php

$port = $client->ports()->reset(
    '10000',
    '7c838e2d-7d52-42e7-aed1-528829cbd514',
);

Сигнал	Что он подтверждает
HTTP `200` с объектом `Port`	Запрос сброса принят и возвращен текущий снимок порта
Запись о сбросе в `GET /ports/{id}/log`	Действие сброса записано в журнал
Другое значение `ip` в `GET /ports/{id}`	Наблюдаемый API публичный IP изменился
Вебхук `port.ip_changed`	LTESocks зафиксировал смену IP и передал старое и новое значения

Предпочитайте вебхук port.ip_changed. Без вебхуков опрашивайте GET /ports/{id} с ограниченным backoff и сравнивайте ip со значением до сброса. Один только статус не подтверждает смену IP.

Cooldown сброса

Минимальный cooldown между пользовательскими сбросами — 60 секунд. Настройки пула порта могут требовать более долгого ожидания, поэтому 60 секунд — нижняя граница, а не обещание доступности следующего сброса.

Когда сброс временно недоступен, документированный ответ об ошибке может содержать:

Заголовок	Значение
`Retry-After`	Целое количество секунд ожидания, округленное вверх
`Retry-At`	Абсолютное время следующей попытки в формате RFC 3339

Если присутствуют оба заголовка, ждите до более позднего вычисленного момента, чтобы учесть расхождение часов. Не повторяйте сброс немедленно при отсутствии заголовков: примените ограниченный backoff и сначала проверьте порт.

Для полной смены IP нет документированного сквозного времени. Готовность нового подключения зависит от сети и назначенного модема.

Автоматические сбросы

Интервал настраивается через POST /ports/{id}/autoreset:

{
  "autoResetInterval": 600
}

Значение	Поведение
`0`	Автоматические сбросы отключены
`1`–`179`	Значение может сохраниться, но планировщик не выполняет сбросы с таким интервалом; не используйте его
`180` и больше	Поддерживаемые мобильные порты планируются с интервалом в секундах

Интервал отсчитывается от соответствующего назначения порта или точки планирования. Сброс не запустится раньше срока, но это не точное расписание по часам. Выполнение асинхронно и требует поддерживаемого, не отключенного порта из пула с назначенным модемом.

Готовность после заказа

POST /ports/order возвращает снимок созданного порта, но сам по себе ответ не подтверждает готовность прокси-подключения и IP для рабочего трафика.

Передайте Idempotency-Key с заказом и сохраните возвращенное значение port.
После тайм-аута повторите точный запрос с тем же ключом вместо создания нового заказа.
Читайте GET /ports/{id}, пока порт не получит пригодный IP, и проверяйте подключение с ограниченной стратегией повторов.
Подключите вебхуки, если нужна событийная обработка смены IP.

Полная таблица решений находится на странице Идемпотентность и безопасные повторы, а поля и фильтры журналов — в разделе Управление портами.