Registro de cambios

v3.2: Un nuevo sistema de pedidos: una sola lista de errores, drip feed más simple, cancelación y reposición más claras

Todo lo siguiente se publica a la vez bajo la cabecera X-NotPanel-API-Version: 2026-10. Toda acción anterior sigue funcionando, y las direcciones /api/v1, /api/v2 y /api/v3 se comportan igual.

• Cada pedido tiene un único número que sirve en el panel, en soporte y en la API. Los pedidos de la API conservan sus números anteriores.
• Drip feed: runs con interval sigue funcionando. La nueva forma simple toma la quantity total y drip_feed_total_minutes, hasta 48 horas.
• La cancelación es instantánea con reembolso completo durante los primeros 15 segundos. Después puedes solicitar una cancelación donde el servicio lo admita, con reembolso automático. order devuelve un objeto, como antes; orders devuelve un array.
• La reposición funciona una vez cada 6 horas por pedido, sin fecha límite y con un motivo claro cuando se rechaza.
• Las reacciones de Telegram son un único campo reactions, ya sea una mezcla (👍,❤️,🔥) o recuentos exactos (👍:60,❤️:40), comprobado antes de que se te cobre.
• La lista de servicios muestra etiquetas, campos adicionales con límites, límites de drip feed y disponibilidad. cancel: true ahora significa que las solicitudes de cancelación funcionan de verdad.
• Cada error tiene un código fijo, un estado HTTP y un indicador retryable. Los códigos anteriores y los actuales se enumeran abajo.
• Nuevo order_details, que también puede encontrar un pedido por tu request_id.
• status incluye el reembolso: en un pedido cancelado o parcial, refund es el importe reembolsado, así que no hace falta otra llamada. refund_quote es un nombre anterior que devuelve la misma respuesta que status.
• Los webhooks son ahora un único sistema: un evento firmado por llamada, con versión, con eventos nuevos para pedidos cancelados y parciales y para los resultados de reposiciones.
• Eliminado: los cuerpos de webhook por lotes, el parámetro coupon y, de status, los campos refund_pending y los dos campos de política de reembolso. El antiguo parámetro delay ya no se lee; usa drip_feed_total_minutes.
• Añadido: can_cancel en status e instant_cancel_until en la respuesta de add. El anterior cancel_available se mantiene en ambos, y cancel_window_seconds y cancel_before se mantienen en la respuesta de add.
• Se mantiene: las acciones catalog y account_status siguen funcionando como antes, y catalog ahora se documenta en Listar servicios. Los nombres de parámetros anteriores siguen funcionando: referer, lpost_count, hashtag para listas de hashtags, usernames separados por comas y el antiguo mapa de reacciones. webhook.add también acepta los nombres de evento order.refunded y order.refill_completed.
• /api/v1, /api/v2 y /api/v3 siguen funcionando y se comportan igual. /api/v3 es la que se documenta.
• Un pedido completado siempre muestra remains como 0.

v3.1: Nombres de servicios adaptados al mercado

Las acciones services y catalog ahora aceptan un código de idioma opcional para nombres elaborados con terminología de mercado seleccionada en diez idiomas. Las solicitudes explícitas añaden metadatos del nombre canónico y del idioma real, y vuelven al inglés de forma segura si falta una traducción o quedó desactualizada. Sin language, la estructura antigua en inglés no cambia. Los administradores pueden revisar o ajustar cada nombre.

v3.0: v3 se convierte en la API predeterminada

/api/v3 pasó a ser el endpoint canónico y un reemplazo directo de URL base para el contrato reseller conocido. v3 añade claves exactas opcionales, protección legacy de 60 segundos, catálogo avanzado, IDs numéricos, refund_quote, account_status, cancelación individual o masiva secuencial y webhooks firmados. El rendimiento de la API ahora usa un nivel basado en lifetime successful spend y una ventana móvil de 60 segundos compartida por todas las claves de la cuenta. /api/v1 y /api/v2 son alias exactos del mismo contrato actual.

v2.5: Catálogo avanzado, conciliación de reembolsos y cancelación

Se añadieron las acciones catalog paginada y refund_quote de solo lectura, se ampliaron los metadatos de add y status y se estableció una ventana de cancelación de 15 segundos para pedidos ordinarios por API. Los eventos de webhook de la API ahora llevan un id de evento estable, mientras que deliveryId permanece estable entre reintentos del mismo lote; cada reintento recibe una marca de tiempo y una firma nuevas. La entrega de webhooks sigue siendo de mejor esfuerzo con reintentos, sin garantía duradera de entrega al menos una vez.

v2.4: 12 nuevas plataformas de medios en el catálogo

Se añadieron servicios para Google, Rumble, Audiomack, Tumblr, Kwai, Clubhouse, Vimeo, Deezer, Tidal, Apple Music, Quora y GitHub. Aparecen en la acción services como cualquier otro servicio y cada uno tiene una página pública de plataforma dedicada. No se requieren cambios en el cliente: los nuevos IDs de servicio simplemente aparecen en el catálogo.

v2.3: Disponibilidad del servicio aplicada al añadir

Los servicios no disponibles rechazan action=add en vez de aceptar o encolar silenciosamente un pedido nuevo. Actualiza el catálogo y elige un servicio disponible antes de reintentar.

v2.2: Parámetros de pedido opcionales

La acción add ahora acepta campos opcionales compatibles específicos del tipo de servicio, como un retraso inicial y opciones de interacción por tipo. Los campos ya definidos por un tipo de servicio conservan su significado documentado.

v2.1: Parámetros de drip-feed al realizar el pedido

La acción add acepta runs e interval juntos para servicios con dripfeed=true. La entrega total es quantity × runs y no puede superar el máximo del servicio. Los servicios sin drip-feed rechazan estos campos.