API do SisTelMax — v1

Confere a chave e devolve os escopos dela. Não exige escopo nenhum.

{ "data": { "ok": true, "version": "1.0",
           "account": "Integração X",
           "scopes": ["customers:read","invoices:read"] } }

Identifica o cliente por CPF/CNPJ ou por telefone — as duas portas de um PBX quando o telefone toca. Aceita o documento com ou sem pontuação, e o telefone com ou sem DDD e nono dígito.

{ "data": [ {
    "id": "83f3b7be-…",  "code": "DEMO001",
    "name": "ANA PAULA DEMONSTRACAO",
    "document": "11111111111",   "document_masked": false,
    "status": "ativo",   "blocked": false,
    "due_day": 10,
    "address": { "street": "Rua da Amostra", "number": "100", "district": "Centro" }
} ] }

blocked responde direto à pergunta que se faz na ligação — “posso atender ou está cortado?” — sem você precisar conhecer os nomes internos de situação. Quem deve mas ainda não foi cortado aparece comblocked: false, porque ele ainda navega.

O documento só sai inteiro quando foi ele o parâmetro da busca.Procurando por phone, ele vem mascarado (529*****25) e document_masked vemtrue: dá para conferir com quem está na linha, e não dá para montar uma base de CPF varrendo telefones. Sempre só dígitos — você não precisa limpar pontuação.

Faturas do cliente, com tudo o que se usa para pagar.

{ "data": [ {
    "id": "c6f91d1f-…",
    "reference": "2026-12-01",     "due_date": "2026-12-15",
    "amount_cents": 6000,          "status": "aberto",
    "overdue": false,
    "installment": 1,              "installments": 12,
    "pix_code": "00020101021226940014BR.GOV.BCB.PIX…",
    "barcode": "36490.00027 00044.074706 00000.381640 1 0000…",
    "pdf_url": "https://…"
} ] }

status usa o mesmo vocabulário da tela do sistema (aberto, vencido, pago,identificado, expirado, cancelado). Traduzir para inglês criaria dois nomes para a mesma coisa.

Como está o acesso do cliente. Só isso.

{ "data": {
    "service_status": "bloqueado",
    "plan": { "name": "Fibra 600 MB" }     // ou null
} }

Nada financeiro sai aqui — nem quantas faturas estão vencidas, nem o valor que o cliente paga. Isso é invoices:read, de propósito: uma chave que só precisa saber se o acesso está no ar não deve receber junto a situação financeira da pessoa.

plan.name é o nome público do plano, e vem nullquando a operadora não publicou um — o que hoje é comum. O rótulo interno de cobrança nunca sai.

blocked e service_status podem discordar, e não é defeito: blocked (em /customers) é a situação do cadastro; service_status é a do acesso. Um cliente pode estar ativo no cadastro e bloqueado na rede, ou o contrário, durante uma sincronização. Para decidir se atende, useservice_status.

As ordens de serviço do cliente.

{ "data": [ {
    "number": 1042,
    "subject": "Sem sinal",          "category": "manutencao",
    "work_type": "manutencao",       "stage": "em_atendimento",
    "opened_by_api": true,
    "created_at": "2026-08-31T14:02:11Z"
} ] }

stage tem três valores: recebida,em_atendimento (já tem técnico) e concluida.

O que não sai, e é de propósito: o nome e o id do técnico (dado pessoal de funcionário), a descrição livre digitada pelo atendente, o setor e quem abriu internamente. O subject é o nome do tipo de chamado, nunca o texto do chamado.

{ "category": "manutencao",
  "description": "cliente relata queda de sinal desde ontem à noite" }

Categorias possíveis: manutencao, religamento,cancelamento, outros — mas só as que a operadora liberar para a API funcionam. Sem liberação, a resposta é422 dizendo isso.

description precisa de pelo menos 15 caracteres: é o que o técnico vai ler antes de sair. Máximo de 300.

Cada abertura avisa um técnico de verdade. Por isso há teto diário por chave e freio por cliente — e por isso a operadora escolhe, uma a uma, quais categorias a API pode abrir.