Journal des modifications

v3.2: Un nouveau système de commandes : une seule liste d'erreurs, une alimentation progressive plus simple, une annulation et une recharge plus claires

Tout ce qui suit est livré ensemble sous l'en-tête X-NotPanel-API-Version: 2026-10. Chaque action existante continue de fonctionner, et les adresses /api/v1, /api/v2 et /api/v3 se comportent de façon identique.

• Chaque commande a un numéro unique qui sert dans le tableau de bord, auprès du support et dans l'API. Les commandes API conservent leurs anciens numéros.
• Alimentation progressive : runs avec interval fonctionne toujours. La nouvelle forme simple prend la quantity totale et drip_feed_total_minutes, jusqu'à 48 heures.
• L'annulation est instantanée avec remboursement intégral pendant les 15 premières secondes. Ensuite, vous pouvez demander une annulation lorsque le service le permet, avec remboursement automatique. order renvoie un objet, comme avant ; orders renvoie un tableau.
• La recharge fonctionne une fois toutes les 6 heures par commande, sans date limite et avec un motif clair en cas de refus.
• Les réactions Telegram forment un seul champ reactions, soit en mélange (👍,❤️,🔥), soit avec des nombres exacts (👍:60,❤️:40), vérifié avant que vous ne soyez débité.
• La liste des services affiche les étiquettes, les champs supplémentaires avec leurs limites, les limites d'alimentation progressive et la disponibilité. cancel: true signifie désormais que les demandes d'annulation fonctionnent réellement.
• Chaque erreur a un code fixe, un statut HTTP et un indicateur retryable. Les anciens codes et les codes actuels sont listés ci-dessous.
• Nouveau order_details, qui peut aussi retrouver une commande grâce à votre request_id.
• status inclut le remboursement : pour une commande annulée ou partielle, refund est le montant remboursé, aucun appel séparé n'est donc nécessaire. refund_quote est un ancien nom qui renvoie la même réponse que status.
• Les webhooks forment désormais un seul système : un événement signé par appel, versionné, avec de nouveaux événements pour les commandes annulées et partielles et pour les résultats de recharge.
• Supprimés : les corps de webhook groupés, le paramètre coupon et, dans status, les champs refund_pending et les deux champs de politique de remboursement. L'ancien paramètre delay n'est plus lu ; utilisez drip_feed_total_minutes.
• Ajoutés : can_cancel dans status et instant_cancel_until dans la réponse de add. L'ancien cancel_available reste dans les deux, et cancel_window_seconds et cancel_before restent dans la réponse de add.
• Conservées : les actions catalog et account_status continuent de fonctionner comme avant, et catalog est désormais documentée dans Lister les services. Les anciens noms de paramètres fonctionnent toujours : referer, lpost_count, hashtag pour les listes de hashtags, usernames séparés par des virgules et l'ancienne table des réactions. webhook.add accepte aussi les noms d'événement order.refunded et order.refill_completed.
• /api/v1, /api/v2 et /api/v3 continuent toutes de fonctionner et se comportent de la même façon. /api/v3 est celle qui est documentée.
• Une commande terminée affiche toujours remains à 0.

v3.1: Noms de services adaptés au marché

Les actions services et catalog acceptent désormais un code de langue facultatif pour des noms rédigés avec une terminologie de marché sélectionnée dans dix langues. Les demandes explicites ajoutent les métadonnées du nom canonique et de la langue réelle, avec retour sûr à l’anglais si une traduction manque ou est obsolète. Sans language, la structure historique en anglais reste inchangée. Les administrateurs peuvent vérifier ou affiner chaque nom.

v3.0: v3 devient l'API par défaut

/api/v3 devient l'endpoint canonique et un remplacement direct d'URL de base pour le contrat reseller familier. v3 ajoute des clés exactes facultatives, une protection legacy de 60 secondes, le catalogue avancé, des ID numériques, refund_quote, account_status, l'annulation unitaire ou par lot séquentiel et les webhooks signés. Le débit API utilise désormais un niveau fondé sur le lifetime successful spend et une fenêtre glissante de 60 secondes partagée par toutes les clés du compte. /api/v1 et /api/v2 sont des alias exacts du même contrat actuel.

v2.5: Catalogue avancé, réconciliation des remboursements et annulation

Ajout des actions catalog paginée et refund_quote en lecture seule, enrichissement des métadonnées de add et status et fenêtre d'annulation de 15 secondes pour les commandes ordinaires via l'API. Les événements de webhook de l'API portent désormais un id d'événement stable, tandis que deliveryId reste stable lors des nouvelles tentatives d'un même lot ; chaque tentative reçoit un nouvel horodatage et une nouvelle signature. La livraison des webhooks reste assurée au mieux avec des tentatives, sans garantie durable de livraison au moins une fois.

v2.4: 12 nouvelles plateformes médias dans le catalogue

Ajout de services pour Google, Rumble, Audiomack, Tumblr, Kwai, Clubhouse, Vimeo, Deezer, Tidal, Apple Music, Quora et GitHub. Ils apparaissent dans l'action services comme n'importe quel autre service et chacun dispose d'une page de plateforme publique dédiée. Aucune modification côté client requise — les nouveaux ID de service apparaissent simplement dans le catalogue.

v2.3: Disponibilité du service appliquée lors de l’ajout

Les services indisponibles rejettent action=add au lieu d’accepter ou de mettre silencieusement une nouvelle commande en file. Actualisez le catalogue et choisissez un service disponible avant de réessayer.

v2.2: Paramètres de commande facultatifs

L’action add accepte désormais des champs facultatifs pris en charge et propres au type de service, comme un délai initial et des options d’engagement par type. Les champs déjà définis par un type de service conservent leur sens documenté.

v2.1: Paramètres d'alimentation progressive à la passation de commande

L’action add accepte runs et interval ensemble pour les services avec dripfeed=true. La livraison totale est quantity × runs et ne peut pas dépasser le maximum du service. Les services sans drip-feed rejettent ces champs.