Mudanças que quebram compatibilidade e mudanças notáveis na API v3. Seguimos o semver — mudanças aditivas (novos parâmetros opcionais, novas ações, novos campos nas respostas) são lançadas dentro de uma versão principal; mudanças que quebram compatibilidade vão em uma nova versão principal.
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.
/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.
Foram adicionadas as ações catalog paginada e refund_quote somente para leitura, ampliados os metadados de add e status, criada uma janela de cancelamento de 15 segundos para pedidos comuns via API e um reembolso integral para um pedido comum não resolvido 7 dias após sua criação original. 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.
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.
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.
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.
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.
Lançou a API de ações v2 codificada em formulário com controlos de taxa, webhooks assinados de melhor esforço com novas tentativas e criação idempotente de pedidos. Os URLs v1 e v2 atuais são aliases do contrato v3 e usam o limite partilhado da conta documentado.