Dados de uso
Os quatro comportamentos que mais causam erros nas integrações: valores não medidos, campos vazios por tipo, a contagem de conexões e um limite de tráfego que não depende da medição.
Esses comportamentos não são falhas; refletem como os dados são produzidos conforme o tipo de serviço e o backend.
Não medido, não zero
Se o backend não puder ser acessado, os contadores retornam null, e não 0. Verifique o campo usage.available; mostrar valores null como zero faz o cliente ler "você não usou nada".
const { usage } = (await res.json()).data;
const label = usage.available ? `${usage.gb_used} GB` : "Não é possível medir agora";Campos sempre vazios por tipo
Não é uma falha; aquele backend não produz aquele dado.
| Campo | ISP / Datacenter / Gaming | Mobile / Residential |
|---|---|---|
success_count | ✓ | null |
error_count | ✓ | null |
active_connections | null | ✓ |
source | logs | proxy_controller |
Na família ISP, requisição = conexão
Em ISP, Datacenter e Gaming, total_requests, success_count, error_count e requests no histórico de uso contam conexões; uma única conexão keep-alive pode levar várias requisições HTTP. bytes_in são os dados baixados e bytes_out, os enviados.
gb_limit não depende da medição
Mesmo com available false, gb_limit pode vir preenchido; o limite é lido do banco de dados.
Histórico de uso
GET /orders/{id}/usage-history retorna uma série diária. Na família ISP, requests conta as conexões encerradas no dia; em Mobile/Residential, as requisições do dia. Se meta.available for false, uma fonte não pôde ser lida, e os dias faltantes não significam uso zero; se nada puder ser lido, retorna503 service_unavailable.