Por que um timeout da API SMM pode cobrar duas vezes — e por que a NotPanel não cobra
Timeout não é falha. Na maioria das APIs de painel SMM, retry é um segundo pedido. A NotPanel exige request_id para o mesmo add não debitar duas vezes.
Envias add. O TCP cai. O cliente faz timeout. Envias o mesmo pedido outra vez — o que mais farias?
Nas páginas públicas da JustAnotherPanel e da CheapSMMPanel esse segundo add é um segundo pedido. Dois débitos. Um cliente. Os docs de convidado não falam de idempotência. Os samples PHP não enviam chave.
Na NotPanel o segundo add é o mesmo pedido. Recusamos action=add sem request_id do caller. Mesma chave, mesmo corpo, o id original. Não é slogan. É o contrato de criação de pedido.
Da última vez que um add deu timeout, o que o teu cliente fez?
Toque numa opção. Fica só neste dispositivo — não é uma pesquisa inventada.
A falha que ninguém escreve
Depois de um timeout três coisas podem ser verdade ao mesmo tempo. Não sabes qual. Toca num cartão.
Timeout é um desconhecido, não uma falha. Páginas v2 clonadas tratam como falha: add outra vez. É assim que child panels acordam com cobrança dupla.
Comparação completa: JustAnotherPanel vs CheapSMMPanel vs NotPanel.
Como é um retry seguro
A regra que funciona de verdade
request_id=550e8400-e29b-41d4-a716-446655440000
Se o servidor criasse a chave, cada retry criaria outra. Teatro. Por isso não a geramos por ti. O guia de integração tem a forma do cliente.
Timeout é um desconhecido. O único retry seguro é o que o servidor reconhece como o mesmo pedido.
Novo não é o risco. Um contrato que não podes testar é.
Um painel de dez anos com a mesma página /api fotocopiada não é “de confiança”. É familiar. O familiar ainda cobra duas vezes quando a rede pisca.
A NotPanel é mais nova. O contrato é público: /developers, changelog, códigos de erro, headers de rate-limit. Podes provar o retry com uma chave de staging esta noite. É assim que se vê confiança quando o dinheiro anda em HTTP.
A seguir: webhooks vs polling de status para um child panel.
FAQ
Porque é que a API do meu painel SMM cobrou duas vezes?
Normalmente timeout mais retry. O primeiro add chegou e a resposta não. O segundo add foi um pedido novo porque o painel não tinha chave de idempotência do caller. Os docs de convidado da JustAnotherPanel e da CheapSMMPanel não documentam nenhuma.
A JustAnotherPanel suporta pedidos idempotentes?
Não nessa página pública de API. Não há request_id (nem equivalente) no add. O sample PHP oficial não envia. Trata um retry como segundo pedido a menos que documentem noutro sítio que possas citar.
Qual é a melhor API de painel SMM se retries importam?
A que exige uma chave do caller no add e devolve o pedido original quando essa chave é repetida. A NotPanel faz isso. As páginas v2 clonadas do mercado não. “Melhor catálogo” e “melhor preço” são outras perguntas e mudam todas as semanas.
Um painel SMM novo é menos fiável?
Não se puderes testar o caminho do dinheiro. Um contrato público, request_id obrigatório e uma chave de staging que podes enviar duas vezes esta noite batem uma década de um one-pager sem assinatura. Familiar não é o mesmo que seguro.
Quem deve gerar request_id?
Tu. Uma vez. Fora do loop de retry. Se o servidor gerar, cada retry teria outra chave e voltavas a dois pedidos. A NotPanel rejeita add sem ela.