Credentials and proxy authentication

Proxy traffic and platform API calls use different credentials. Keep the two systems separate in code, secret storage, and incident response.

Gateway credentials

A package username plus proxy password authorizes traffic on HTTP or SOCKS5 gateway ports.

Platform credentials

A JWT or static API key authorizes control-plane requests under the assigned deployment API hostname.

Gateway credential anatomy

The username carries both the package identity and optional routing instructions:

package-elite-country-us-sid-checkout-42-ttl-1800
└── base ───┘ └ target ┘ └──── session controls ────┘

The password remains a separate secret. Do not append targeting tokens to the password and do not substitute a dashboard login password.

Proxy URL

http://{proxy_username}:{proxy_password}@{proxy_host}:{proxy_port}

cURL flags

−+×

RequestGET https://api.ipify.org?format=json

curl 'https://api.ipify.org?format=json' \
  --proxy 'http://{proxy_host}:{proxy_port}' \
  --proxy-user '{proxy_username}:{proxy_password}'

−+×

Response200 OK

{
  "ip": "203.0.113.42"
}

Replace placeholders in braces with your values. Responses use synthetic example data.

Separating --proxy-user can make shell quoting and secret injection easier.

Secret-handling rules

1. Store proxy passwords in a secret manager or protected server environment.
2. Inject them at runtime instead of writing them into configuration committed to Git.
3. Redact full proxy URLs from application logs and support screenshots.
4. Rotate a password after suspected exposure and update all workers as one rollout.
5. Use distinct secrets per deployment when the platform configuration supports it.

Log a credential fingerprint

For diagnostics, log a short one-way fingerprint and the order ID—not the username/password pair. This lets operators correlate failures without exposing reusable access.

IP allowlist and domain policy

Gateway access still uses a proxy username and password. An IP allowlist is an additional restriction: when configured for a user, connections must also originate from an allowed address. It is not a passwordless authentication mode.

The allowlist size is deployment-specific. Do not build UI validation around a global fixed number; confirm the configured limit during onboarding and handle an API validation error without discarding the user’s existing list.

User domain blocklists are separate from authentication and provider selection. A blocklist denies configured destinations; it does not choose a provider or proxy type for an allowed request.

API keys have their own network restriction

A platform API key can also carry an allowed-IP policy. Keep API-key source restrictions separate from the proxy user’s gateway allowlist.

Common authentication failures

Symptom	Check first
407 Proxy Authentication Required	Username/password pair, order activity, and the correct gateway port
Immediate connection refusal	Hostname, port, firewall, and protocol mismatch
Works without targeting but fails with it	Token spelling and inventory availability
API returns 401	The API Authorization header, not proxy credentials

For API credentials, continue to API fundamentals.