Comparação de APIs de painéis SMM: JAP, CheapSMMPanel e NotPanel
Comparamos três APIs SMM públicas por campos, tentativas, webhooks e erros HTTP: apenas o que os contratos mostram.
Abri três páginas públicas de API: JustAnotherPanel, CheapSMMPanel e NotPanel. A comparação é sobre o contrato, não sobre preço ou tamanho do catálogo.
Duas páginas repetem o formato v2 conhecido. As diferenças importantes aparecem depois do primeiro POST: nomes de campos, identidade do retry, webhooks e código de status.
O que impediria você de apontar um painel filho para um novo upstream?
Toque numa opção. Fica só neste dispositivo — não é uma pesquisa inventada.
O placar
As três usam um POST no estilo v2 com formulário e resposta JSON. Depois disso, deixam de ser intercambiáveis.
Um cliente JAP precisa remapear campos para falar com a CheapSMM. Para criar um pedido no NotPanel também precisa de request_id; essa diferença é intencional.
O mesmo pedido de exemplo. A mesma fotocópia.
As páginas públicas usam o pedido de demonstração e o fluxo básico de listar, adicionar, consultar status e saldo. Isso serve para a primeira chamada, mas não explica o que acontece quando a rede falha.
Um exemplo prova a sintaxe, não o comportamento de retries, eventos assinados ou tratamento de falhas. Revise o contrato público antes de colocar a integração em produção.
Nomes de campos não são detalhe
| Função | JAP / NotPanel | CheapSMMPanel |
|---|---|---|
| Autenticação | key | api_token |
| Catálogo | action=services | action=packages |
| Id do serviço | service | package |
| Contagem inicial | start_count | start_counter |
| Status | In progress / in_progress | Title case in examples |
A CheapSMM chama a migração de simples, mas trocar autenticação, catálogo, serviço e quantidade toca cada chamada. Trocar a URL base não é um plano de migração.
Status também importa. Se o reconciliador reembolsa qualquer valor diferente de completed, uma diferença de nomes vira perda de dinheiro.
Por que a NotPanel é mais forte onde importa
São diferenças de contrato que você pode verificar, não uma promessa sobre preço ou tamanho do catálogo.
Pedidos seguros contra retries
add exige request_id. Repetir a mesma chave e o mesmo corpo retorna o pedido original; um corpo diferente é rejeitado.
Ver o contrato de add →Eventos de status assinados
A referência de webhooks define HMAC-SHA256 sobre o corpo original, com timestamp e evento; URLs privadas ou locais são rejeitadas.
Verificar uma entrega →Erros explícitos
A API documenta respostas HTTP 400, 403, 429 e 500 para o cliente distinguir entrada inválida, bloqueio, limite ou falha do serviço.
Ler erros e respostas →Limites visíveis
As respostas publicam X-RateLimit-Limit, Remaining e Reset, além do contexto de tier e do motivo do bloqueio quando aplicável.
Ver os limites →Cada ponto pode ser testado na referência pública antes de migrar um fluxo de reseller.
Timeout não é falha
Os clientes públicos de exemplo não mostram um identificador fornecido pelo chamador. O NotPanel exige request_id em todo add: mesma chave e mesmo corpo retornam o id original; corpo diferente é rejeitado.
Gere a chave uma vez, fora do loop de retry. Timeout é resultado desconhecido, não prova de que o pedido não ocorreu.
Veja a referência de criação de pedido · guia de integração.
Timeout é desconhecido. O único retry seguro é aquele que o servidor reconhece.
Polling versus envelope assinado
JAP e CheapSMM não documentam webhooks de saída em suas páginas públicas. A integração implícita é consultar status até o texto mudar. Funciona, mas gasta limite em pedidos parados.
O NotPanel oferece webhook.add, list e remove. Cada entrega inclui HMAC-SHA256 do corpo bruto, timestamp e evento. URLs privadas e link-local são rejeitadas; a entrega é pelo menos uma vez e o handler precisa ser idempotente.
As receitas estão na referência de webhooks · guia de HMAC.
Status HTTP, não 200 com erro
Uma especificação clonada pode retornar HTTP 200 com um objeto de erro. Uma biblioteca que confia apenas no status tratará isso como sucesso.
Os limites têm camadas de IP, chave e nível. Leia as referências de erros e rate limits antes de criar um loop de retry.
Esse é o argumento: automatizar com um contrato sem inventar a metade ausente. Leia a documentação pública antes de mover tráfego. notpanel.com/developers.
Os dois vazamentos de dinheiro têm guias próprias: retries de timeout e webhooks versus polling.
FAQ
A JustAnotherPanel tem API de reseller?
Sim. A página v2 pública mostra key e action para services, add, status, refill, cancel e balance. Não documenta webhooks, idempotência, catálogo de erros HTTP ou headers de limite.
Qual a diferença entre a API JAP e a NotPanel?
O formato v2 básico é parecido, mas o NotPanel exige request_id, documenta webhooks assinados, retorna status de erro explícitos e publica headers de limite. A JAP documenta mais campos especiais e cancelamento.
CheapSMMPanel usa a mesma API que a JAP?
Não. A documentação pública usa api_token, action=packages, package e start_counter. Um cliente JAP não funciona sem alterações.
Painéis SMM têm webhooks?
Alguns têm, mas muitas páginas v2 não os mencionam. Se a documentação nunca falar de assinatura, trate POSTs recebidos como não confiáveis.
Por que o NotPanel exige request_id?
Um add com timeout tem resultado desconhecido. Sem uma chave do chamador, o retry pode ser outra cobrança; mesma chave e corpo retornam o pedido original.
Posso apontar um cliente JAP existente para o NotPanel?
Leituras normalmente precisam apenas revisar URL e status. add exige request_id, cancel não é exposto e campos especiais devem estar documentados.