Usage data
The four behaviors that cause the most integration bugs: unmeasured values, fields that are empty by type, connection counting, and a traffic limit that does not depend on measurement.
These behaviors are not faults; they reflect how the data is produced for each service type and backend.
Unmeasured, not zero
If the backend cannot be reached, the counters return null, not 0. Check the usage.available field; showing null values as zero tells your customer "you haven't used anything".
const { usage } = (await res.json()).data;
const label = usage.available ? `${usage.gb_used} GB` : "Can't be measured right now";Fields that are always empty by type
Not a fault; that backend does not produce that data.
| Field | ISP / Datacenter / Gaming | Mobile / Residential |
|---|---|---|
success_count | ✓ | null |
error_count | ✓ | null |
active_connections | null | ✓ |
source | logs | proxy_controller |
In the ISP family, request = connection
On ISP, Datacenter and Gaming, total_requests, success_count, error_count and requests in the usage history count connections; a single keep-alive connection can carry several HTTP requests. bytes_in is downloaded data, bytes_out is uploaded data.
gb_limit does not depend on measurement
gb_limit can be filled in even when available is false; the limit is read from the database.
Usage history
GET /orders/{id}/usage-history returns a daily series. In the ISP family requests counts the connections closed that day; on Mobile/Residential it counts that day's requests. If meta.available is false, a source could not be read and the missing days are not zero usage; if nothing can be read, 503 service_unavailable is returned.