Traffic and time
Request ID, transferred bytes, timestamp, protocol, method, cluster, and the number of established connections observed for the request.
Analytics and reconciliation
Analytics turns completed proxy activity into operational and commercial evidence. Use it to answer what consumed traffic, which destinations and targeting combinations were used, where failures occurred, and whether your local billing projection still matches the platform.
01Proxy requestTraffic, routing, identity, and connection context
02Request snapshotOne normalized record after the request or tunnel closes
03ClickHouse + RedisHistorical request rows and current connection counters
04Public API viewsOverall, domains, feed, logs, transactions, connections
User · reseller · package · ledger · username
Bytes · request ID · timestamp · active connections
Hostname · client IP · proxy server IP · protocol · method
Pool · country · region · city · ASN · sticky session
What the proxy captures
Section titled “What the proxy captures”After a request or tunnel closes, the proxy builds an analytics snapshot from the authenticated user and the actual route it handled. A valid historical record includes identity, client, destination, and provider context; live connection counts are stored separately for the connections view.
Commercial scope
User, reseller, package, ledger, package alias, and proxy username connect a request back to the order and customer that consumed it.
Destination and routing
Destination hostname, client and proxy-server IPs, selected pool, requested country, region, city, ASN, and sticky-session presence.
Failure context
Error logs add HTTP status, internal proxy error code, message, severity, server, targeting, and session context for request-level diagnosis.
The proxy also records provider identity internally. The current public request feed exposes the selected pool, not the underlying provider. It returns ASN as a result field, but the public query contract does not currently offer ASN or ISP filters.
Choose the view that answers your question
Section titled “Choose the view that answers your question”| Question | Endpoint | Returned view | Why it is useful |
|---|---|---|---|
| How many connections are active now? | GET /analytics/connections | User, package, server IP, connection count | Capacity dashboards, concurrency support, and detecting abandoned clients |
| How did traffic change over time? | GET /analytics/overall | Time buckets with bytes and request count | Usage charts, anomaly detection, customer summaries, and closed-window reconciliation |
| Which destinations consume the most? | GET /analytics/domains | Hostname, requests, and bytes | Cost concentration, customer behavior, allow/block policy reviews, and abuse investigation |
| What happened on an individual request? | GET /analytics/feed | Request-level identity, traffic, destination, protocol, pool, geo, ASN, and session data | Reproducing routing behavior and explaining a customer’s traffic record |
| Why did requests fail? | GET /analytics/logs | Status, proxy error code/message, identity, destination, geo, and timestamp | Support triage, provider incident correlation, and retry-policy tuning |
| Who allocated or consumed data? | GET /analytics/{id}/transactions | Sender, recipient, type, amount, package, details, and time | Billing audit trails and tracing reseller-to-sub-user data movements |
Overall traffic
Section titled “Overall traffic”overall is the primary chart and reconciliation surface. It fills missing buckets with zeroes and returns both data and requests. Short windows use hour-level buckets; longer windows use daily buckets. Always store the requested start, end, and IANA timezone next to your own report so the same commercial period can be reproduced.
Activity feed and domains
Section titled “Activity feed and domains”Use feed when you need evidence at request granularity and domains when you need a ranked aggregate. Feed rows can distinguish customers, packages, and ledgers; show the destination and client/proxy IPs; and explain the protocol, method, pool, targeting, ASN, and sticky-session usage associated with the byte count.
Domain aggregation is better for questions such as “which destinations generated 70% of traffic?” without downloading every request row. Treat destination hostnames as potentially sensitive customer data.
Connections and logs
Section titled “Connections and logs”connections is an operational snapshot rather than a historical traffic report. Compare its per-server counts with package concurrency limits to distinguish real capacity pressure from a historical usage spike.
logs reads proxy warning/error records, not successful requests. Filter it by protocol, error code, package, ledger, account, or location where supported. Correlate a log row with feed data using time, request context, identity, and destination instead of exposing full proxy credentials in a support ticket.
Transactions
Section titled “Transactions”Transactions describe data movements and consumption records with sender/recipient scope. For non-staff callers, sender and recipient filters are constrained to the authenticated account. Use this view as an audit trail around allocations; use overall and the durable order/ledger state for traffic totals.
Scope and filters
Section titled “Scope and filters”Every analytics request is evaluated inside the authenticated account boundary:
- a regular user can query only its own
user_id; - a reseller can query its own user or one of its direct sub-users;
- a reseller may request its own
reseller_idfor a reseller-wide view where the endpoint supports it; - platform administrators can use broader scopes, but customer integrations should not depend on administrative access.
| Filter group | Values | Typical use |
|---|---|---|
| Reporting window | start, end, timezone | Reproducible billing and operational periods |
| Pagination | limit, offset | Bounded feed, log, domain, and transaction exports |
| Commercial scope | user_id, reseller_id, package_id, ledger_id | One customer, product, purchase pool, or reseller portfolio |
| Request details | hostname, protocol | Destination investigation and HTTP/SOCKS comparison |
| Targeting | country, region, city | Inventory and routing-quality analysis |
| Failure and movement | error_code, sender_id, recipient_id, type | Error clustering and allocation audits |
Not every endpoint accepts every filter. Region requires country, and city requires country and region. Use the Analytics operations in the API Reference as the exact per-endpoint contract.
Practical B2B uses
Section titled “Practical B2B uses”Protect gross margin
Compare traffic by customer, package, and destination with the commercial plan to identify costly workloads and plans priced below their usage shape.
Improve support
Move from “the proxy failed” to a bounded request, time, protocol, location, pool, and error code that engineering can reproduce.
Plan capacity
Combine active connections with traffic trends to detect concurrency saturation separately from byte-volume growth.
Reconcile resellers
Compare sub-user activity and transaction history with your local customer, allocation, invoice, and webhook projections.