Plan proxy cleanup and refill lifecycle honestly

Define the end of a proxy task

A proxy task ends when the approved client work is finished and no further traffic should be generated. That does not automatically delete the proxy user or revoke its credentials. The current Lupin public proxy routes expose creation, listing, reading, top-up and pool balance, without a standalone user-delete, password-reset or general policy-update endpoint. Plan the operator handoff for unsupported lifecycle changes before allocation. Do not describe a stopped client as a deleted resource or promise that a resource ID disappearing from a local task record prevents the credentials from being used elsewhere.

Choose a finite policy at creation when needed

Creation defaults auto_refill to true and uses quota_mb or traffic_mb as the opening target. If the approved task needs a one-time bounded allocation, set auto_refill false from the start. The API does not currently provide a general endpoint to toggle that field afterward. Automatic refill can allocate more traffic when individual-user reads or the background sweep synchronize an active user. The default threshold in code is the smaller of one hundred MB and ten percent of quota. A remaining balance is therefore not a lifetime spending ceiling when refill is enabled.

Stop the client and retain a final account

Stop scheduled requests, background workers and retries associated with the task. Record opening allocation, observed usage, refill events and any unresolved provider outcome. A browser or sandbox that happened to use a proxy-capable client has its own lifecycle and must be cleaned up separately. The current managed Browser Run product does not support custom Lupin proxy routing at all. Do not assume ending a browser session deletes a proxy user, or that stopping a sandbox revokes credentials copied into another system. Resource boundaries remain distinct even when a single task created them.

{"username":"one-time-task","quota_mb":100,"auto_refill":false}

Handle adjustments as explicit operations

Manual top-up accepts a nonzero amount and is a sensitive paid-management operation. Preserve its Idempotency-Key and obtain the exact authorized amount and purpose. The schema permits negative adjustments, but that should not be described as a guaranteed customer refund or universal resource-revocation mechanism. Actual provider and billing behavior must be checked for the configured deployment. A failed or ambiguous adjustment needs reconciliation before another attempt. Likewise, a low-pool event can reflect a refill failure beyond a simple lack of funds, so investigate rather than buying capacity automatically to clear an alert.

Use the operator lifecycle for unsupported changes

When credentials must be revoked, policy changed or a user retired, give the authorized operator the resource identifier, current policy and reason. Project cleanup paths can have provider lifecycle logic, but broad project deletion is not a substitute for a missing narrow proxy endpoint and can affect unrelated resources. Keep the user's intended scope explicit. If future work needs more traffic, treat renewal as a new approved allocation stage rather than assuming an old task authorized continuing spend forever. Finish with a clear statement of stopped client activity, retained resource state and any operator action still required.

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 · authentication-methods · user-pass-authentication ↗Checked 2026-11-05
• docs.dataimpulse.com · resellers · deposit-calculation-update ↗Checked 2026-11-05

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