A API SMM deu timeout. Você deve enviar o pedido novamente?

Repita o pedido com o request_id original e os mesmos parâmetros. Não crie outra chave só porque a conexão expirou. No NotPanel, a nova tentativa devolve o pedido original com replayed: true, ou cria o pedido se a primeira tentativa nunca chegou.

O cliente fez uma compra. Se a resposta desaparecer depois do envio ao painel, o próximo passo deve recuperar essa compra sem transformar a dúvida em uma nova compra.

Um timeout deixa três possibilidades

• A solicitação não chegou e nenhum pedido foi aceito.
• O pedido foi aceito, mas a resposta se perdeu.
• A solicitação chegou enquanto a conexão falhava; uma nova tentativa com o mesmo request_id esclarece qual dos dois casos anteriores aconteceu.

O timeout não distingue esses casos. O HTTP sozinho não torna seguro repetir um POST que cria uma compra; a proteção vem do contrato da API. Veja RFC 9110, §9.2.2.

Como o NotPanel reconhece uma repetição

request_id é opcional, não pode estar vazio e aceita até 128 caracteres. idempotency_key é seu alias; quando ambos aparecem, request_id prevalece. Mantenha a mesma conta, chave e parâmetros. Um pedido aceito retorna o ID original; reutilizar a chave com parâmetros diferentes é rejeitado.

Sem as duas chaves, o NotPanel protege add idênticos da mesma conta por 60 segundos: uma repetição dentro desse prazo devolve o primeiro pedido em vez de criar outro. Não dependa dessa janela para repetições posteriores.

Duas compras intencionalmente iguais também são agrupadas nessa janela. Use um request_id próprio para cada nova compra quando quiser separá-las imediatamente. Não troque a chave para contornar uma resposta incerta.

Parâmetros e respostas de criação de pedidos

Identifique a compra antes do envio

Para a linha de compra 8427, salve request_id e todos os parâmetros antes da primeira tentativa. O esquema usa marcadores e quebras de linha; codifique o formulário real normalmente. Só envie valores reais se quiser fazer um pedido pago.

POST https://notpanel.com/api/v3
Content-Type: application/x-www-form-urlencoded

key=YOUR_API_KEY
&action=add
&service=YOUR_SERVICE_ID
&link=YOUR_TARGET_URL
&quantity=YOUR_VALID_QUANTITY
&request_id=checkout-8427-line-1

Após o timeout, reenvie checkout-8427-line-1 com serviço, destino, quantidade e campos opcionais idênticos, inclusive após reiniciar o aplicativo. Salve o ID retornado e use-o em status. request_id identifica a criação, não substitui o ID de pedido na consulta de estado. Para localizar um pedido pelo request_id, use order_details.

Leia a resposta completa

Timeout ou resposta incerta

Mantenha chave e parâmetros. Limite as tentativas, faça pausas e respeite Retry-After. Ao esgotar as tentativas, mantenha o registro pendente.

INTERNAL_ERROR, API_DISABLED ou ORDER_PLACEMENT_PAUSED (retryable: true)

Aguarde, respeitando Retry-After quando presente, e envie o mesmo add com o mesmo request_id. Você recebe o pedido original ou um único pedido novo. Não crie outro com uma chave diferente.

REQUEST_ID_CONFLICT

Compare os parâmetros salvos. Recupere o pedido usando os originais; uma nova chave é para uma compra deliberadamente distinta.

Validação, autenticação ou limite de requisições

Leia error_code e retryable. Corrija os dados ou credenciais e respeite as esperas. Não repita qualquer erro automaticamente.

Teste a recuperação antes das compras dos clientes

Comece com uma API simulada no seu ambiente de testes. Não é necessária uma compra real nem uma chave especial do NotPanel.

1. Simule um pedido aceito cuja resposta se perde; confirme a mesma chave e os mesmos parâmetros.
2. Reinicie o cliente e recupere a identidade salva.
3. Devolva primeiro um 500 ou 503 que permita nova tentativa e depois uma repetição com replayed: true; confirme que o cliente salva um único ID de pedido.
4. Simule conflito ou erro não repetível; confirme que o ciclo para.
5. Crie duas novas compras idênticas com chaves distintas. Em um teste real posterior, use um pedido desejado e confira pedido e movimentações da carteira.

Perguntas frequentes

Timeout significa cobrança duplicada?

Não. Significa que você não recebeu uma resposta utilizável. Confira o pedido recuperado e as movimentações da carteira antes de concluir que houve duas cobranças.

request_id é obrigatório?

Não. request_id e idempotency_key são opcionais. Sem eles, add idênticos da mesma conta recebem proteção por 60 segundos. A chave explícita identifica cada compra.

Devo gerar outra chave a cada tentativa?

Não. Salve uma chave antes da primeira tentativa e reutilize-a com o pedido inalterado. Uma compra nova recebe outra chave.

Posso localizar um pedido com request_id?

Sim, com order_details: envie action=order_details com o mesmo request_id para obter o pedido e seu número sem repetir o add. Se nenhum pedido foi criado, a resposta é ORDER_NOT_FOUND. A ação status continua exigindo o número do pedido.

Continue com: o guia de integração · webhooks e consultas de estado · a referência de erros.