Integration pattern
Request an endpoint, hand it to the worker, and let the worker retire it when the task ends. Treating endpoints as disposable keeps a failed job from poisoning a long-lived credential, and makes it trivial to attribute traffic to the process that generated it.
Authentication models
| Model | How it works | Use when |
|---|---|---|
| User / password | Credentials in the proxy string | Dynamic workers, laptops, browser profiles |
| IP whitelist | Server address pre-registered | Fixed infrastructure, cron jobs |
| Sub-account | Scoped credentials with own quota | Teams, clients, per-project budgets |
What the API covers
- Endpoint generation — build host:port credentials with geography and session type baked in.
- Sub-accounts — separate teams or clients with their own limits and reporting.
- Whitelisting — register server IPs so automated jobs skip password auth.
- Usage — pull consumption per account, per period, for internal billing.
Frequently asked questions
Is API access included?
Yes, on all plans. There is no separate API tier or add-on fee.
Can I create sub-accounts programmatically?
Yes — sub-accounts, their quotas and their credentials are all API-managed.
Does whitelisting replace passwords?
For registered server addresses, yes. Whitelisting is the cleaner option for fixed infrastructure.
Are there rate limits?
Normal usage is not throttled. Very high-frequency provisioning is best batched rather than looped per request.