Datos de uso
Los cuatro comportamientos que más errores causan en las integraciones: valores no medidos, campos vacíos según el tipo, el recuento de conexiones y un límite de tráfico que no depende de la medición.
Estos comportamientos no son fallos; reflejan cómo se generan los datos según el tipo de servicio y el backend.
No medido, no cero
Si no se puede acceder al backend, los contadores devuelven null, no 0. Comprueba el campo usage.available; mostrar los valores null como cero le dice al cliente «no has usado nada».
const { usage } = (await res.json()).data;
const label = usage.available ? `${usage.gb_used} GB` : "No se puede medir ahora";Campos siempre vacíos según el tipo
No es un fallo; ese backend no genera ese dato.
| Campo | ISP / Datacenter / Gaming | Mobile / Residential |
|---|---|---|
success_count | ✓ | null |
error_count | ✓ | null |
active_connections | null | ✓ |
source | logs | proxy_controller |
En la familia ISP, solicitud = conexión
En ISP, Datacenter y Gaming, total_requests, success_count, error_count y requests del historial de uso cuentanconexiones; una sola conexión keep-alive puede transportar varias solicitudes HTTP. bytes_in son los datos descargados y bytes_out, los subidos.
gb_limit no depende de la medición
Aunque available sea false, gb_limit puede llegar con valor; el límite se lee de la base de datos.
Historial de uso
GET /orders/{id}/usage-history devuelve una serie diaria. En la familia ISP, requests cuenta las conexiones cerradas ese día; en Mobile/Residential, las solicitudes de ese día. Si meta.available es false, no se pudo leer alguna fuente y los días que faltan no significan uso cero; si no se puede leer nada, devuelve503 service_unavailable.