Set a proxy traffic budget that does not refill unexpectedly

Budget the operation before allocating traffic

Define the approved task, expected destinations, request count and maximum useful response size before creating a proxy user. A proxy allocation is a paid resource operation, and a human-verified workspace with the right permissions and billing readiness is required. The bootstrap key cannot create paid users. Decide whether the task needs a one-time traffic allocation or an ongoing replenished service. Those are materially different spending policies. An agent should not enable an open-ended refill loop merely because a tutorial's default made the first connection convenient or because the remaining balance was difficult to interpret.

Choose opening quota and refill explicitly

The creation contract accepts quota_mb, traffic_mb, auto_refill and low_threshold_mb. Quota is the balance target, not a hard lifetime usage ceiling when auto-refill is enabled. Auto-refill defaults to true, so set it false at creation when the approved work needs a strictly finite opening allocation. The current API does not expose a general update route to change those fields later. Avoid promising an agent can toggle refill after starting. Use a stable Idempotency-Key for creation so a lost response cannot lead to another allocation under a fresh identity.

Understand the retail accounting boundary

The shared customer billing catalog currently prices proxy.allocated_mb at $3 per 1,000 MB. That is a price for allocated capacity under the decimal GB convention, not a second charge computed directly from each observed client byte. The derived used_mb value subtracts remaining traffic from cumulative allocation, while refills can make the remaining amount look stable. Keep opening allocation and refill events in the budget record. Upstream provider plans, deposits and special targeting charges are separate facts; they do not automatically define a new customer retail tier or a feature the Lupin API exposes.

{"username":"bounded-client","quota_mb":100,"auto_refill":false,"threads":2}

Bound the client workload too

Set request timeouts, cap concurrency and avoid downloading unnecessary large bodies. A small intended response can redirect or return an error page, so inspect the actual content and status. Retries consume traffic and can multiply work even when they never produce a useful result. Distinguish transient connection failures from deterministic authentication, exhausted balance or target restrictions before retrying. If you control the workload, add an application-level stopping rule based on completed requests and observed bytes. Do not assume a provider dashboard's traffic-limit feature is available through Lupin's current public API unless the integration explicitly exposes it.

Monitor without hiding refill effects

Reading an active proxy user can synchronize usage and trigger configured auto-refill; a background sweep can do the same. Treat those reads as potentially connected to paid allocation and follow the approved policy. The default low-water mark in code is min(100, quota times 0.1), not a minimum one hundred MB. Synchronization failures can leave stored values stale. When the task finishes, stop client traffic and report allocated capacity, observed usage, refill events and any uncertainty separately. A clear finite budget is a combination of resource policy and bounded client behavior, not just a number displayed as remaining.

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 · traffic-limit ↗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.