Distinguish proxy rotation from a supported API control

Separate connection behavior from management controls

A rotating proxy route and a management API's rotate command are different capabilities. The current Lupin proxy surface exposes user creation, listing, reading, traffic top-up and pool balance. It does not expose a dedicated immediate rotate-IP endpoint. The provider documents rotating and sticky connection behavior, but that does not make every upstream parameter a first-class Lupin API field. Start with the connection details returned for the configured resource and the task's actual continuity requirement. Do not design an agent loop around an invented rotate method merely because rotation is a familiar proxy feature.

Define why continuity matters

Some approved tasks need several requests to retain a consistent route, while independent public fetches may not require that continuity. A sticky route can reduce address changes during a short interaction, but it is not a permanent dedicated-IP promise. Network availability and provider behavior still apply. Do not use route continuity as a substitute for application authentication or as a reason to ignore the destination's access policy. If the task needs an allowlisted fixed address, verify that requirement against a product designed to provide it instead of assuming a residential sticky configuration satisfies it.

Interpret sticky_days narrowly

Lupin's creation schema accepts sticky_days as an integer from zero through thirty and passes it into the provider adapter's sticky field. That mapping should not be described as a tested guarantee of retaining one exit address for that many days. Upstream public documentation also describes port-based sticky connections and session-related parameters with their own semantics. Those are separate contracts that require validation for the configured reseller resource. Do not combine similarly named fields into a new undocumented lifetime promise. Record the actual provider configuration and observed behavior if a continuity claim is essential to the task.

{"username":"continuity-task","quota_mb":100,"auto_refill":false,"sticky_days":0}

Verify the client configuration deliberately

Use the returned host, port, username and supported schemes rather than replacing them with an upstream tutorial's rotating or sticky ports. The current connection block can expose one endpoint, and its completeness depends on live provider response mapping. A small approved diagnostic can observe the route at several points, but it cannot establish an indefinite guarantee. Keep the test within its traffic budget and avoid logging credentials. If an operation fails, classify authentication, traffic capacity, target availability and destination restrictions before changing rotation assumptions or allocating another proxy user.

Plan recovery without magical rotation

If continuity is lost, inspect the application's current state and decide whether the task can safely continue or must restart an authorized logical stage. A new IP does not roll back a submitted request, restore a session cookie or deduplicate an external effect. Preserve operation identities for management allocations and application-level idempotency for consequential destination actions. The public API has no general policy-update or credential-reset catalog, so involve the operator for unsupported changes. Report the exact limitation: the observed route behavior and exposed controls are narrower than a universal ability to choose and rotate addresses on demand.

Sources & verification

Reviewed against the current Lupin route, provider adapter and shared input contracts, plus the linked official references. Examples were not run against live services.

• docs.dataimpulse.com · proxies · types-of-connections ↗Checked 2026-11-05
• docs.dataimpulse.com · proxies · parameters ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.