Comparación de API de paneles SMM: JAP, CheapSMMPanel y NotPanel
Comparamos tres API SMM públicas por sus campos, reintentos, webhooks y errores HTTP: solo lo que muestran sus contratos.
Abrí tres páginas públicas de API: JustAnotherPanel, CheapSMMPanel y NotPanel. La comparación trata del contrato, no de precios ni del tamaño del catálogo.
Dos páginas repiten la forma v2 conocida. Las diferencias importantes aparecen después del primer POST: nombres de campos, identidad del reintento, webhooks y código de estado.
¿Qué te impediría conectar un panel hijo a un nuevo proveedor?
Toca una. Se guarda solo en este dispositivo — no es una encuesta inventada.
El marcador
Las tres usan un POST estilo v2 con formulario y respuesta JSON. Después dejan de ser intercambiables.
Un cliente JAP necesita remapear campos para hablar con CheapSMM. Para crear un pedido en NotPanel también necesita request_id; es una diferencia intencional.
El mismo pedido de ejemplo. La misma fotocopia.
Las páginas públicas usan el pedido de demostración y el flujo básico de listar, añadir, consultar estado y ver saldo. Sirve para la primera llamada, pero no explica qué ocurre cuando falla la red.
Un ejemplo demuestra la sintaxis, no el comportamiento de los reintentos, los eventos firmados ni el manejo de errores. Revisa el contrato público antes de poner la integración en producción.
Los nombres de campo importan
| Función | JAP / NotPanel | CheapSMMPanel |
|---|---|---|
| Autenticación | key | api_token |
| Catálogo | action=services | action=packages |
| Id del servicio | service | package |
| Conteo inicial | start_count | start_counter |
| Estados | In progress / in_progress | Title case in examples |
CheapSMM llama sencilla a la migración, pero cambiar autenticación, catálogo, servicio y cantidad toca cada llamada. Cambiar la URL base no es un plan de migración.
Los estados también importan. Si un conciliador reembolsa cualquier valor que no sea completed, una diferencia de nombres puede convertirse en una pérdida.
Por qué NotPanel es más sólido donde importa
Son diferencias de contrato que puedes comprobar, no una promesa sobre precios o tamaño del catálogo.
Pedidos seguros ante reintentos
add exige request_id. Repetir la misma clave y el mismo cuerpo devuelve el pedido original; un cuerpo diferente se rechaza.
Ver el contrato de add →Eventos de estado firmados
La referencia de webhooks define HMAC-SHA256 sobre el cuerpo original, con marca de tiempo y evento; las URL privadas o locales se rechazan.
Verificar una entrega →Errores explícitos
La API documenta respuestas HTTP 400, 403, 429 y 500 para que el cliente pueda distinguir una entrada inválida, un bloqueo, un límite o un fallo del servicio.
Leer errores y respuestas →Límites visibles
Las respuestas publican X-RateLimit-Limit, Remaining y Reset, además del contexto de tier y del motivo del bloqueo cuando aplica.
Ver los límites →Cada punto se puede probar contra la referencia pública antes de migrar un flujo de reseller.
Un timeout no es un fallo
Los clientes públicos de ejemplo no muestran un identificador aportado por quien llama. NotPanel exige request_id en cada add: la misma clave y el mismo cuerpo devuelven el id original; cambiar el cuerpo se rechaza.
Genera la clave una vez, fuera del bucle de reintento. Un timeout es un resultado desconocido, no una prueba de que el pedido nunca ocurrió.
Lee la referencia para crear pedidos · guía de integración.
Un timeout es desconocido. El único reintento seguro es el que el servidor puede reconocer.
Polling frente a un sobre firmado
JAP y CheapSMM no documentan webhooks salientes en sus páginas invitadas. La integración implícita es consultar status hasta que cambie. Funciona, pero consume límite en pedidos inmóviles.
NotPanel ofrece webhook.add, list y remove. Cada entrega incluye HMAC-SHA256 del cuerpo original, timestamp y evento. Las URL privadas y link-local se rechazan; la entrega es al menos una vez y el handler debe ser idempotente.
Las recetas están en la referencia de webhooks · guía HMAC.
Código de estado, no 200 con error
Una especificación clonada puede devolver HTTP 200 con un objeto de error. Una librería que solo confía en el estado lo tratará como éxito.
Los límites tienen capas de IP, clave y nivel. Revisa errores y rate limits antes de crear un bucle de reintento.
Ese es el argumento: automatizar con un contrato sin inventar la mitad que falta. Lee la documentación pública antes de mover tráfico. notpanel.com/developers.
Los dos escapes de dinero tienen guías propias: reintentos por timeout y webhooks frente a polling.
FAQ
¿JustAnotherPanel tiene API para resellers?
Sí. Su página v2 pública muestra key y action para services, add, status, refill, cancel y balance. No documenta webhooks, idempotencia, catálogo de errores HTTP ni headers de límites.
¿Cuál es la diferencia entre la API de JAP y la de NotPanel?
La forma v2 básica es parecida, pero NotPanel exige request_id, documenta webhooks firmados, devuelve estados de error explícitos y publica headers de límites. JAP documenta más campos especializados y cancelación.
¿CheapSMMPanel usa la misma API que JAP?
No. Sus documentos usan api_token, action=packages, package y start_counter. Un cliente JAP no funciona sin cambios.
¿Los paneles SMM admiten webhooks?
Algunos sí, pero muchas páginas v2 no los mencionan. Si la documentación no habla de firma, trata los POST entrantes como no confiables.
¿Por qué NotPanel exige request_id?
Un add con timeout tiene resultado desconocido. Sin una clave del llamador, el reintento puede ser otro cargo; con la misma clave y cuerpo se devuelve el pedido original.
¿Puedo apuntar un cliente JAP existente a NotPanel?
Las lecturas suelen requerir solo revisar URL base y estados. add necesita request_id, cancel no está expuesto y los campos especiales deben estar documentados.