Deliver proxy credentials through a narrow trust boundary

Separate management from connection authority

The Lupin API key authorizes management operations such as creating a proxy user or allocating traffic. The proxy username and password authorize client connections to the returned endpoint. Keep those roles separate: the application should not give a customer its workspace management key merely to let the customer's HTTP client use a proxy. A human-verified workspace, proxy permissions, billing readiness and a configured live provider are prerequisites for allocation. The autonomous bootstrap key cannot create paid proxy users or increase its own authority. Design the credential handoff before creating the resource so secrets do not fall into a general activity log.

Read the actual creation response

A successful live creation may include a connection block containing host, port, username, password and supported schemes. Use those returned values rather than hardcoding an upstream hostname or borrowing a port from a provider tutorial. The normalization layer supports several upstream response shapes, and the current code explicitly notes that live field mapping needs provider verification. If host or required credentials are missing, report the integration as incomplete instead of inventing them. The local log provider is a deterministic development path and does not demonstrate a usable upstream connection; it may return no connection block at all.

Do not promise later password retrieval

The route serializes connection details when provider credentials are available during creation. Ordinary list and get serialization does not guarantee a connection block or a recoverable password. Store an approved credential copy in your secure delivery or secret-storage system if the product requires later connection setup. Do not tell a customer that reading the resource again will necessarily redisplay its password. The current public API also does not expose a general password-reset or credential-rotation operation. An upstream dashboard feature is not automatically a Lupin endpoint your client can call.

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

Deliver only to the intended human or client

Use an authenticated interface with appropriately restricted access, and avoid including full proxy URLs in support tickets, analytics or shared transcripts. A URL that embeds user and password is still a secret even when it looks like a convenient configuration string. Redact credentials from HTTP client debug output and screenshots. The agent tool catalog treats proxy-user reads and management as sensitive, including the possibility that a read triggers refill. A plain resource identifier and sanitized status are usually enough for routine progress reporting. Provide connection secrets only where the authorized setup actually needs them.

Verify with a small approved connection test

Once live provider readiness and the traffic budget are approved, configure the client's supported proxy scheme and make a bounded harmless request to an appropriate destination. Do not claim the credential works merely because resource creation returned JSON. Authentication, endpoint reachability and target access can fail independently. Record the sanitized outcome without copying the password, and keep allocation accounting separate from test bytes. If the credentials leak or need replacing, use the supported operator process rather than inventing a reset endpoint or allocating another paid user without resolving the original resource.

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
• curl.se · docs · manpage.html ↗Checked 2026-11-05

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