Create and edit packages

A package is the product contract customers buy. It joins identity, lifecycle, price, enforced limits, eligible supply, gateway scope, targeting, and proxy-username behavior. Orders grant a user access to a package and its data ledger.

Before you create a package

Have these decisions approved first:

residential or static product type;
public catalog visibility or private assignment;
expiration policy;
customer-facing name, stable alias, description, features, and internal tag;
fixed tiers or range pricing, currency, and reseller commission;
connection, speed, and data policy;
validated provider mix and optional pools;
global or selected gateway scope;
advertised location and session targeting.

Use a private package for first tests. Creation is immediate and produces an active record.

Step 1: product setup

Package creation wizard product type and visibility — Start with the choices that determine which later fields and routes are compatible.
Product type selects the residential or static configuration path.
Visibility controls catalog discovery; private packages can still be assigned by authorized operators.

Choose Residential for traffic-metered rotating or sticky access through one or more upstream providers. Choose Static for dedicated inventory linked to a compatible static provider. Visibility affects discovery, not the validity of an existing entitlement.

Package expiration and customer-facing identity fields — Complete lifecycle and identity while the live package preview exposes inconsistent choices.
Expiration policy must match checkout, invoice, renewal, and support language.
Name, alias, description, features, and tag separate customer identity from internal grouping.

Treat the alias as stable after credentials are distributed. Describe only capabilities you have tested end to end. Supplier names belong in provider configuration, not necessarily in a white-label customer product.

Step 2: pricing and limits

Package pricing model, commission, and live review — Choose the commercial model first, then verify how it appears in the package review.
Pricing model and reseller commission define how offers are calculated.
The review summary updates as configuration changes and should match the approved product.

Pricing model	Use it when	Validate
Fixed tiers	Customers choose exact offers such as 1 GB or 10 GB	Unique amounts, intentional effective price, correct expiry
Range tiers	Customers enter an amount inside allowed bands	No gaps or overlaps; boundary pricing is correct
One-time tier	The offer must not renew	Checkout and entitlement match the one-time label

Define whether customer-facing “GB” is decimal or binary and use the same conversion in prices, orders, ledgers, invoices, and UI.

Package connection and speed limit controls with sellable tiers — Limits use explicit presets first; custom inputs appear only when an operator chooses to configure them.
Connection and speed controls distinguish unlimited/default behavior from a deliberate custom value.
Every sellable tier pairs a price with an explicit data or quantity amount.

Use the preset buttons for the normal policy. Choose the custom option only when the product needs a numeric limit, then enter a non-negative whole value in the revealed input. Unlimited data removes byte-ledger enforcement for that package, but traffic still appears in analytics.

Step 3: routing and review

Package provider traffic allocation and routing readiness — A package becomes routable only when its provider allocation satisfies the required total.
Add only validated providers and assign the intended relative traffic allocation.
Routing readiness confirms that the accepted provider total has been reached.

Provider weights apply among routes that remain eligible after protocol, location, provider capability, health, customer access, pool policy, and session constraints. They express selection intent, not a guaranteed billing split.

You can also attach reusable pools and restrict the package to selected gateway servers. Leaving gateway selection empty uses the eligible deployment scope. Select specific servers only for deliberate isolation, staged rollout, or a dedicated footprint.

Package targeting capabilities and final create action — Advertise only the selectors that every intended production route can honor.
Enable continent, country, region, city, ASN, and advanced mappings only after live validation.
The final action creates an active package and records the change in the audit log.

Advanced username mapping controls how location, session, operating-system, and related tokens are represented in proxy credentials. Changing it can break existing integrations; use a migration plan or a new package when the grammar is already distributed.

Post-creation acceptance test

Read the package from the customer catalog and verify name, features, price tiers, and targeting.
Create an internal user and order; confirm the active ledger or unlimited state.
Generate rotating and sticky credentials with a valid TTL.
Test HTTP, HTTPS CONNECT, SOCKS5, and UDP only where advertised.
Test a broad country and the narrowest supported location or ASN combination.
Confirm provider, package, server, request-feed, domain, and error analytics.
Exhaust a small test allocation and verify ledger, webhook, and access transitions.
Make the package public only after all required routes pass.

Edit an existing package safely

Package edits can affect active customers. Alias, username mapping, provider/pool allocation, gateway scope, targeting, expiry, limits, and pricing are compatibility-sensitive.

Inventory

Record current values and identify active orders before changing the contract.

Isolate

Prefer a new private package for a materially different product.

Verify

Test existing and newly generated credentials after each logical change.

Observe

Review errors, health, closed analytics, and audit evidence before wider rollout.

Continue with customers and data accounting to grant access and understand how usage is charged.