How allocation works
When you create a sub-user, you allocate bandwidth to it from your main (primary) package. The bandwidth you allocate is deducted from the main package. For example, say your main package has 10 GB and you create 3 sub-users with 1 GB each:
The 3 GB you allocated moves from the main package to the sub-users. Your total bandwidth doesn’t change — only how it’s divided.
Top-ups go to the main package
When you top up on the website, the bandwidth is added to your main package. Top-ups never create a new package. To give a sub-user more bandwidth, top up your main package and allocate from it.Why use sub-users
- Per team or customer. Give each team or customer their own credentials and bandwidth, so one can’t use up another’s.
- Per workload. Isolate a high-volume scrape from smaller jobs, so a runaway job can only spend its own allocation.
- Per environment. Keep staging and production traffic apart, with separate usage.
- Contain leaks. If a set of credentials is exposed, only that sub-user’s bandwidth is at risk.
Connecting as a sub-user
Sub-users connect exactly like the main package — same gateway, ports, and parameters — with their own username and password:Sub-users in the Customer API
Packages returned by the Customer API include asubuser_id and an is_primary flag. is_primary: true marks your main package.
Every package you create with POST /api/customer/orders is created as its own sub-user, with its own credentials. Use GET /api/customer/packages/:id to read a package’s credentials and live usage.
Next steps
Usage analytics
See bandwidth and requests for your traffic.
Billing & top-ups
Pricing, payment methods, and how top-ups work.
Core concepts
How packages, sub-users, and parameters fit together.
Create an order
Create packages programmatically with the Customer API.