Скидання та готовність порту

Створення порту та скидання 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}`	Публічна IP-адреса, яку спостерігає API, змінилася
Вебхук `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.

Повна таблиця рішень наведена на сторінці Ідемпотентність і безпечні повтори, а поля й фільтри журналів — у розділі Керування портами.