Port reset and readiness

Port creation and IP reset both start work that can continue after the API response. Build your integration around observable state rather than a fixed sleep.

Which identifier to send

Use the value of Port.port as {id} in public port routes. For example, a response with "port": "10000" is read with GET /ports/10000 and reset with POST /ports/10000/reset.

Internal object IDs and service IDs are not public port-route identifiers. resetToken is used only by GET /tokens/{token} and does not replace bearer authentication.

Manual reset lifecycle

Send a new UUID idempotency key for each intended reset:

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"

Official SDK

JavaScript

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

Python

from uuid import UUID

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

PHP

<?php

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

Signal	What it proves
HTTP 200 with a Port	The reset request was accepted and the current port snapshot was returned
A reset entry in GET /ports/{id}/log	The reset action was recorded
A different ip from GET /ports/{id}	The public IP observed by the API has changed
port.ip_changed webhook	LTESocks observed an IP change and delivered its old and new values

200 is an acknowledgement

An HTTP 200 response does not mean that IP rotation has finished. The connection and routing can still be converging, and a short interruption is expected.

Prefer the port.ip_changed webhook. Without webhooks, poll GET /ports/{id} with a bounded backoff and compare ip with the value from before the reset. Do not use status alone as proof of an IP change.

Reset cooldown

User-triggered resets have a minimum cooldown of 60 seconds. A port's pool configuration can require a longer wait, so 60 seconds is a lower bound rather than a promise that every reset is available at that moment.

When a reset is temporarily unavailable, the documented error response may include:

Header	Meaning
Retry-After	Whole seconds to wait, rounded up
Retry-At	Absolute retry time in RFC 3339 format

If both are present, wait until the later calculated deadline to tolerate clock differences. Do not immediately retry a reset without these headers; apply bounded backoff and inspect the port first.

There is no documented end-to-end duration for IP rotation. Network conditions and the assigned modem determine when the new connection becomes usable.

Automatic resets

Configure the interval through POST /ports/{id}/autoreset:

{
  "autoResetInterval": 600
}

Value	Behavior
0	Automatic resets are disabled
1–179	The value can be stored, but the scheduler does not run automatic resets at this interval; do not use it
180 or greater	Eligible, supported mobile ports are scheduled in seconds

The interval is measured from the relevant port assignment or scheduling point. It means the reset will not run before it is due; it is not an exact wall-clock schedule. Execution is asynchronous and requires a supported, non-disabled pool-backed port with an assigned modem.

Readiness after ordering

POST /ports/order returns the created port snapshot, but that response alone does not prove that the proxy connection and IP are ready for production traffic.

1. Send an Idempotency-Key with the order and store the returned port value.
2. If the request times out, retry the exact request with the same key instead of creating another order.
3. Read GET /ports/{id} until the port exposes a usable IP and verify connectivity with a bounded retry policy.
4. Subscribe to webhooks when you need event-driven IP-change handling.

See Idempotency and safe retries for the complete retry decision table and Port management for log fields and filters.