Admin panel guide

This guide covers the Vue 3 administration panel used to configure and operate the ProxyRequest service itself. It explains the business meaning of each workspace, the order in which to configure resources, and the checks required before real customers send traffic.

How the system fits together

Upstream providers ──┐
                     ├─> pools / package routing ─> gateway servers ─> destinations
Private supply ──────┘              │
                                    ├─> request analytics and health
Customer ─> order ─> data ledger ───┘
      │
      ├─ proxy credentials and targeting
      └─ API keys / webhooks for automation

The operator supplies upstream contracts and gateway-server capacity. ProxyRequest provides the control plane, gateway software, routing, accounting, customer resources, analytics, and automation surfaces. A package turns compatible supply into the product a customer sees.

On a new installation, the bootstrap imports the canonical location catalog automatically. The operator verifies that baseline, then imports each provider’s translation dictionary from its API or creates the mapping manually. Provider-specific vocabulary is therefore configured after the shared country/region/city catalog, not instead of it.

Admin workspaces

Workspace	Sections	Operator responsibility
Overview	Analytics, settings, audit log	Monitor the deployment, configure global behavior, and review administrative changes
Customers	Users, orders, data ledgers, API keys, webhooks	Provision access, track entitlements and balances, and connect external systems
Commerce	Packages, invoices	Define sellable products, prices, limits, and purchase records
Infrastructure	Providers, pools, clusters, servers	Connect upstream supply, group routes, and operate the gateway footprint
Locations	Canonical catalogs and location dictionaries	Present consistent targeting while translating provider-specific naming

The panel hides actions the signed-in administrator is not allowed to perform. Create separate operator accounts and grant the minimum capabilities needed for support, billing, supply, and infrastructure work.

Recommended configuration order

1. Set deployment identity and access. Configure the customer-facing domains, branding, currencies, payment options, email, and operator roles. Verify that API and proxy DNS resolve to the intended services.
2. Register gateway capacity. Create clusters for operational grouping, register servers, expose the required HTTP/SOCKS ports, and verify online status and throughput.
3. Verify locations and add dictionaries. Confirm the automatically imported continent, country, region, city, and ASN catalog. Import each provider dictionary from its API or create replacements manually before offering narrow targeting.
4. Connect providers. Add credentials, endpoint regions, supported protocols, location formats, and translation rules. Test each provider independently.
5. Create pools where useful. Combine providers by purpose, choose public or private access, set a requested/fixed/random location policy, and assign weights.
6. Create packages. Choose product type, visibility, expiry, pricing, limits, provider allocation, pools, gateway scope, targeting capabilities, and username mapping.
7. Run an internal purchase. Create a test user and order, confirm the data ledger, generate credentials, and test HTTP and SOCKS behavior from an allowlisted source.
8. Connect automation. Create restricted API keys and signed webhooks, then test ambiguous-write recovery and analytics reconciliation.
9. Complete the launch checklist. Exercise location failures, provider health changes, ledger depletion, credential rotation, support access, backups, and incident ownership.

The operating model

Configuration is an intersection

A request succeeds only when package policy, provider capability, live inventory, protocol, geography, customer access, and gateway scope remain compatible.

Accounting has two limits

A root ledger is the physical byte pool. A reseller sub-user allocation is a personal spending limit against that shared pool, not reserved bytes.

Health changes future routes

Unhealthy supply can be excluded from new selections. The gateway does not replay an in-flight customer operation through another provider.

Events require reconciliation

Webhooks make local state responsive. Durable resources and closed analytics windows remain the basis for reconciliation.

Before you invite customers

• use provider test accounts or strict spend limits during setup;
• expose only locations returned as available for the package;
• keep package aliases stable after distributing credentials;
• define decimal GB versus binary GiB once across pricing, allocations, and UI;
• keep API keys, provider passwords, proxy passwords, and webhook secrets in a secret manager;
• assign a human owner for provider incidents, gateway capacity, payments, and customer support;
• document the client-side retry policy for workloads that are safe to repeat;
• verify dashboards and alerts with synthetic traffic before relying on them.

Start with locations and dictionaries, then configure providers and pools and routing. If customers already use another stack, follow the migration and rollout guide before moving production traffic.