La API SMM agotó el tiempo de espera. ¿Debes enviar otra vez el pedido?

Reintenta el mismo pedido con su request_id original y sus parámetros sin cambios. No crees otra clave porque haya expirado la conexión. En NotPanel, el reintento devuelve el pedido original con replayed: true, o lo crea si el primer intento nunca llegó.

El cliente hizo una compra. Si la respuesta desaparece después de enviarla al panel, tu siguiente paso debe recuperar esa compra sin convertir la incertidumbre en otra compra.

Un timeout deja tres posibilidades

• La solicitud nunca llegó y no se aceptó ningún pedido.
• El pedido se aceptó, pero la respuesta se perdió.
• La solicitud llegó mientras fallaba la conexión; un reintento con el mismo request_id aclara cuál de los dos casos anteriores ocurrió.

El timeout no distingue estos casos. HTTP no hace seguro repetir un POST de compra por sí solo; esa protección depende del contrato de la API. Consulta RFC 9110, §9.2.2.

Cómo reconoce NotPanel un reintento

request_id es opcional, no puede estar vacío y admite hasta 128 caracteres. idempotency_key es su alias; si envías ambos, prevalece request_id. Para el mismo pedido, conserva la cuenta, la clave y todos los parámetros. Un pedido aceptado devuelve su ID original; reutilizar la clave con parámetros distintos se rechaza.

Sin ambas claves, NotPanel protege durante 60 segundos los add idénticos de la misma cuenta: una repetición dentro de ese plazo devuelve el primer pedido en lugar de crear otro. No dependas de esa ventana para reintentos posteriores.

Dos compras intencionadamente idénticas también se agrupan dentro de esa ventana. Asigna un request_id distinto a cada compra nueva para separarlas inmediatamente. No cambies la clave para eludir un resultado incierto.

Parámetros y respuestas de creación de pedidos

Identifica la compra antes de enviarla

Para la línea de compra 8427, guarda el request_id y los parámetros completos antes del primer intento. El esquema usa marcadores y saltos de línea; codifica normalmente el formulario real. Solo envíalo con valores reales si quieres realizar un pedido de 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

Después del timeout, vuelve a enviar checkout-8427-line-1 con el mismo servicio, destino, cantidad y campos opcionales, incluso tras reiniciar la aplicación. Guarda el ID devuelto y úsalo en status. request_id identifica la creación; no sustituye al ID de pedido en una consulta de estado. Para buscar un pedido por request_id, usa order_details.

Lee el resultado completo

Timeout o respuesta incierta

Conserva clave y parámetros. Limita los reintentos, espera entre ellos y respeta Retry-After. Si agotas los intentos, conserva el registro pendiente.

INTERNAL_ERROR, API_DISABLED u ORDER_PLACEMENT_PAUSED (retryable: true)

Espera, respetando Retry-After si aparece, y envía el mismo add con el mismo request_id. Obtendrás el pedido original o un único pedido nuevo. No crees un reemplazo con otra clave.

REQUEST_ID_CONFLICT

Compara los parámetros guardados. Recupera el pedido con los originales; una clave nueva corresponde a una compra deliberadamente distinta.

Validación, autenticación o límite de solicitudes

Lee error_code y retryable. Corrige datos o credenciales y respeta las esperas del límite. No repitas automáticamente cualquier error.

Prueba la recuperación antes de atender compras

Empieza con una API simulada en tu entorno de pruebas. No necesitas una compra real ni una clave especial de NotPanel.

1. Simula un pedido aceptado cuya respuesta se pierde; comprueba que se reutilizan clave y parámetros.
2. Reinicia el cliente y recupera la misma identidad guardada.
3. Devuelve primero un 500 o 503 reintentable y después una repetición con replayed: true; comprueba que el cliente guarda un único ID de pedido.
4. Simula un conflicto o error no reintentable; comprueba que el bucle se detiene.
5. Crea dos compras nuevas idénticas con claves diferentes. Para una prueba real posterior, usa un pedido que quieras y revisa pedido y movimientos del monedero.

Preguntas frecuentes

¿Un timeout significa un doble cobro?

No. Significa que no recibiste una respuesta utilizable. Revisa el pedido recuperado y los movimientos del monedero antes de concluir que hubo dos cargos.

¿Es obligatorio request_id?

No. request_id e idempotency_key son opcionales. Sin ellos hay protección de 60 segundos para add idénticos de la misma cuenta. Una clave explícita identifica cada compra.

¿Genero otra clave en cada reintento?

No. Guarda una clave antes del primer intento y reutilízala sin cambiar el pedido. Una compra nueva recibe una clave nueva.

¿Puedo buscar un pedido con request_id?

Sí, con order_details: envía action=order_details con el mismo request_id para obtener el pedido y su número sin repetir el add. Si no se creó ningún pedido, devuelve ORDER_NOT_FOUND. La acción status sigue requiriendo el número de pedido.

Continúa con: la guía de integración · webhooks y consultas de estado · la referencia de errores.