Changelog

v3.2: Um novo sistema de pedidos: uma única lista de erros, drip feed mais simples, cancelamento e reposição mais claros

Tudo abaixo é lançado junto sob o cabeçalho X-NotPanel-API-Version: 2026-10. Toda ação anterior continua funcionando, e os endereços /api/v1, /api/v2 e /api/v3 se comportam de forma idêntica.

• Todo pedido tem um único número que vale no painel, no suporte e na API. Os pedidos da API mantêm seus números antigos.
• Drip feed: runs com interval continua funcionando. A nova forma simples usa a quantity total e drip_feed_total_minutes, até 48 horas.
• O cancelamento é instantâneo com reembolso total durante os primeiros 15 segundos. Depois disso, você pode solicitar um cancelamento onde o serviço aceita, com reembolso automático. order retorna um objeto, como antes; orders retorna um array.
• A reposição funciona uma vez a cada 6 horas por pedido, sem data final e com um motivo claro quando é recusada.
• As reações do Telegram são um único campo reactions, em mistura (👍,❤️,🔥) ou com contagens exatas (👍:60,❤️:40), verificado antes de você ser cobrado.
• A lista de serviços mostra etiquetas, campos extras com limites, limites de drip feed e disponibilidade. cancel: true agora significa que as solicitações de cancelamento realmente funcionam.
• Todo erro tem um código fixo, um status HTTP e um indicador retryable. Os códigos anteriores e os atuais estão listados abaixo.
• Novo order_details, que também pode encontrar um pedido pelo seu request_id.
• status já traz o reembolso: em um pedido cancelado ou parcial, refund é o valor reembolsado, então não é preciso outra chamada. refund_quote é um nome anterior que retorna a mesma resposta que status.
• Os webhooks agora são um único sistema: um evento assinado por chamada, versionado, com novos eventos para pedidos cancelados e parciais e para resultados de reposição.
• Removidos: os corpos de webhook em lote, o parâmetro coupon e, de status, os campos refund_pending e os dois campos de política de reembolso. O antigo parâmetro delay não é mais lido; use drip_feed_total_minutes.
• Adicionados: can_cancel em status e instant_cancel_until na resposta de add. O antigo cancel_available continua nos dois, e cancel_window_seconds e cancel_before continuam na resposta de add.
• Mantidas: as ações catalog e account_status continuam funcionando como antes, e catalog agora está documentada em Listar serviços. Os nomes de parâmetros antigos continuam funcionando: referer, lpost_count, hashtag para listas de hashtags, usernames separados por vírgula e o antigo mapa de reações. webhook.add também aceita os nomes de evento order.refunded e order.refill_completed.
• /api/v1, /api/v2 e /api/v3 continuam funcionando e se comportam da mesma forma. /api/v3 é o documentado.
• Um pedido concluído sempre mostra remains como 0.

v3.1: Nomes de serviços naturais para cada mercado

As ações services e catalog agora aceitam um código de idioma opcional para nomes revisados com terminologia de mercado selecionada em dez idiomas. Pedidos explícitos adicionam metadados do nome canônico e do idioma real e voltam com segurança ao inglês quando uma tradução está ausente ou desatualizada. Sem language, o formato legado em inglês não muda. Os administradores podem revisar ou ajustar cada nome.

v3.0: v3 torna-se a API padrão

/api/v3 virou o endpoint canônico e substituto direto de URL base para o contrato reseller conhecido. v3 adiciona chaves exatas opcionais, proteção legacy de 60 segundos, catálogo avançado, IDs numéricos, refund_quote, account_status, cancelamento individual ou em lote sequencial e webhooks assinados. A capacidade da API agora usa um nível baseado em lifetime successful spend e uma janela móvel de 60 segundos compartilhada por todas as chaves da conta. /api/v1 e /api/v2 são aliases exatos do mesmo contrato atual.

v2.5: Catálogo avançado, reconciliação de reembolso e cancelamento

Foram adicionadas as ações catalog paginada e refund_quote somente para leitura, ampliados os metadados de add e status e criada uma janela de cancelamento de 15 segundos para pedidos comuns via API. Os eventos de webhook da API agora trazem um id de evento estável, enquanto deliveryId permanece estável entre tentativas do mesmo lote; cada tentativa recebe novo horário e assinatura. A entrega de webhooks continua em regime de melhor esforço com tentativas, sem garantia durável de entrega pelo menos uma vez.

v2.4: 12 novas plataformas de mídia no catálogo

Adicionados serviços para Google, Rumble, Audiomack, Tumblr, Kwai, Clubhouse, Vimeo, Deezer, Tidal, Apple Music, Quora e GitHub. Eles aparecem na ação services como qualquer outro serviço e cada um tem uma página pública de plataforma dedicada. Nenhuma mudança é necessária no cliente — novos IDs de serviço simplesmente aparecem no catálogo.

v2.3: Disponibilidade do serviço aplicada ao adicionar

Serviços indisponíveis rejeitam action=add em vez de aceitar ou enfileirar silenciosamente um novo pedido. Atualize o catálogo e escolha um serviço disponível antes de repetir.

v2.2: Parâmetros de pedido opcionais

A ação add passou a aceitar campos opcionais suportados e específicos do tipo de serviço, como atraso inicial e opções de interação por tipo. Os campos já definidos por um tipo de serviço mantêm o significado documentado.

v2.1: Parâmetros de drip-feed na criação de pedidos

A ação add aceita runs e interval juntos para serviços com dripfeed=true. A entrega total é quantity × runs e não pode exceder o máximo do serviço. Serviços sem drip-feed rejeitam estes campos.