Por qué un timeout de la API SMM puede cobrarte dos veces — y por qué NotPanel no lo hará
Un timeout no es un fallo. En la mayoría de APIs de paneles SMM, reintentar es un segundo pedido. NotPanel exige request_id para que el mismo add no debite dos veces.
Lanzas add. Se cae el TCP. El cliente hace timeout. Vuelves a enviar el mismo pedido — ¿qué otra cosa harías?
En las páginas públicas de JustAnotherPanel y CheapSMMPanel ese segundo add es un segundo pedido. Dos débitos. Un cliente. Sus docs de invitado no mencionan idempotencia. Sus samples PHP no envían clave.
En NotPanel el segundo add es el mismo pedido. Rechazamos action=add sin un request_id del llamador. Misma clave, mismo cuerpo, el id original. No es un eslogan. Es el contrato de alta de pedido.
La última vez que un add hizo timeout, ¿qué hizo tu cliente?
Toca una. Se guarda solo en este dispositivo — no es una encuesta inventada.
El fallo que nadie escribe
Tras un timeout pueden ser ciertas tres cosas a la vez. No sabes cuál. Toca una tarjeta.
Un timeout es un desconocido, no un fallo. Las páginas v2 clonadas lo tratan como fallo: add otra vez. Así despiertan los child panels con cargos dobles.
Comparación completa: JustAnotherPanel vs CheapSMMPanel vs NotPanel.
Cómo se ve un reintento seguro
La regla que sí funciona
request_id=550e8400-e29b-41d4-a716-446655440000
Si el servidor mintiera la clave, cada reintento mintiría otra. Teatro. Por eso no la generamos por ti. La guía de integración tiene la forma del cliente.
Un timeout es un desconocido. El único reintento seguro es el que el servidor reconoce como la misma petición.
Lo nuevo no es el riesgo. Un contrato que no puedes probar sí.
Un panel de diez años con la misma página /api fotocopiada no es “de confianza”. Es familiar. Lo familiar igual te cobra dos veces cuando parpadea la red.
NotPanel es más nuevo. El contrato es público: /developers, un changelog, códigos de error, cabeceras de rate-limit. Puedes probar el reintento con una clave de staging esta noche. Así se ve la confianza cuando el dinero viaja por HTTP.
Siguiente: webhooks vs polling de status para un child panel.
FAQ
¿Por qué mi API de panel SMM me cobró dos veces?
Suele ser un timeout más un reintento. El primer add llegó y la respuesta no. El segundo add fue un pedido nuevo porque el panel no tenía una clave de idempotencia del llamador. Los docs de invitado de JustAnotherPanel y CheapSMMPanel no documentan ninguna.
¿JustAnotherPanel soporta pedidos idempotentes?
No en esa página pública de API. No hay request_id (ni equivalente) en add. Su sample PHP oficial no envía uno. Trata un reintento como segundo pedido salvo que lo documenten en un sitio que puedas citar.
¿Cuál es la mejor API de panel SMM si importan los reintentos?
La que exige una clave del llamador en add y devuelve el pedido original cuando se reenvía. NotPanel lo hace. Las páginas v2 clonadas del mercado no. “Mejor catálogo” y “mejor precio” son otras preguntas y cambian cada semana.
¿Un panel SMM nuevo es menos fiable?
No si puedes probar la ruta del dinero. Un contrato público, un request_id obligatorio y una clave de staging que puedes enviar dos veces esta noche ganan a una década de un one-pager sin firma. Familiar no es lo mismo que seguro.
¿Quién debe generar request_id?
Tú. Una vez. Fuera del bucle de reintento. Si lo genera el servidor, cada reintento tendría otra clave y volverías a dos pedidos. NotPanel rechaza add sin él.