# Journal des modifications

## Septembre 2026

### 10 septembre

**Le formulaire HTML envoie désormais un conteneur signé.** À la place des champs de facture séparés — `data` (base64url du JSON) et `signature` (HMAC-SHA256 de la chaîne `data`). L'endpoint est passé de `invoices/createFromForm` à `invoices/form`. Les anciens formulaires ne fonctionnent plus et doivent être reconstruits : voir [Signature du formulaire HTML](./creating-invoices/html-forms/form-signature.md).

### 8 septembre

**Les champs numériques du corps du webhook sont désormais des nombres.** Six champs envoyés auparavant comme des chaînes sont maintenant envoyés comme des nombres : `project.commissionRate`, `invoice.commissionFiatUSD`, `invoice.amountFiatUSD`, `invoice.amountFiat`, `invoice.calcAmountFiat`, `payment.amount`. L'ensemble des champs, leurs noms et leur ordre n'ont pas changé.

Gardez à l'esprit : les zéros finaux sont supprimés, un montant de 10.00 arrive donc comme 10. Les montants sous 0.0001 arrivent en notation exponentielle, par exemple 1.0e-6 — l'analyse JSON standard renvoie le bon nombre ; seule l'analyse manuelle de la chaîne casse.

Les notifications construites avant le déploiement et pas encore remises arrivent dans l'ancien format. Le destinataire doit accepter les deux variantes jusqu'à ce que la file se vide — cela ne prend pas plus de deux jours.

### 6 septembre

**Les champs numériques des réponses de l'API sont désormais des nombres.** Concerne `invoices/list`, `payments/list` et `invoices/create`.

| Champ               | Avant           | Après  |
| ------------------- | ---------------- | ------ |
| `commissionFiatUSD` | `"0.10"`         | `0.1`  |
| `amountFiatUSD`     | `"10.00"`        | `10`   |
| `amountFiat`        | `"1000.00"`      | `1000` |
| `views`             | `"0"`            | `0`    |
| `payment.amount`    | `"10.500000000"` | `10.5` |

**Une clé restreinte à un projet applique désormais la restriction dans toutes les méthodes.** Auparavant, certaines méthodes ignoraient le projet. Maintenant, c'est un filtre dans les méthodes de liste, et une requête sur la facture ou le portefeuille d'un autre projet est rejetée avec `Restricted project`. Une méthode qui ne peut pas respecter la restriction de projet est fermée à une telle clé. Les détails sont dans la section « Portée de la clé ».

**La liste des paiements renvoie désormais les paiements non associés.** Auparavant, `payments/list` ne renvoyait que les paiements liés à une facture. Maintenant, les résultats incluent tous les paiements de vos portefeuilles ; un paiement non associé n'a pas de bloc `invoice`. Ce sont exactement les paiements nécessaires à l'association manuelle via `invoices/bindPayment`.

**L'annulation de facture distingue désormais les raisons de refus.** Auparavant, une facture absente comme des conditions non remplies renvoyaient un `Invoice not found` générique. Maintenant, `Invoice not found` signifie uniquement que la facture n'existe pas, tandis que des conditions non remplies renvoient `Invoice cannot be canceled`.

**Les identifiants mal formés sont désormais rejetés.** `invoices/list` valide `invoiceId`, `invoiceUid` et `projectId` ; `payments/list` — `walletId` et `invoiceId`. Une valeur qui ne convient pas renvoie `Parameter is filled in incorrectly` avec le nom du champ. Auparavant, un tel paramètre était silencieusement ignoré et les résultats revenaient non filtrés.

**Les bornes de période incluent désormais toute la journée nommée.** `startDate` et `endDate` sont interprétés de `00:00:00` à `23:59:59`. Auparavant, le jour de fin était entièrement coupé, et une requête sur une seule journée ne renvoyait que les enregistrements créés exactement à minuit. Concerne `invoices/list`, `payments/list`, `statistics/invoices` et `statistics/payments`.

**Un champ projet a été ajouté à l'historique du solde.** Chaque opération de la méthode `billing/history` porte désormais un champ `projectId`. Pour les opérations au niveau du compte — recharges et bonus — il vaut `null`.

### 4 septembre

**La description et les données de service reviennent sous leur forme d'origine.** Les champs `description` et `serviceData` étaient auparavant stockés encodés, et dans les réponses de l'API un guillemet arrivait comme `&quot;` et un signe inférieur comme `<`. Maintenant, c'est exactement ce que le marchand a soumis qui est renvoyé. À l'affichage en HTML, échappez la valeur de votre côté.

**Les formulaires HTML n'acceptent que POST.** Créer une facture en suivant un lien avec des paramètres dans la barre d'adresse ne fonctionne plus — les paramètres ne sont lus que depuis le corps de la requête. Si vous utilisiez des liens, remplacez-les par un formulaire avec `method="post"`.

### 3 septembre

**Les notifications de webhook sont désormais signées.** Les en-têtes `X-Timestamp` et `X-Signature` ont été ajoutés ; la signature est calculée en HMAC-SHA256 avec le secret du webhook. Vérifier la signature permet de distinguer une notification authentique d'une contrefaçon. La mécanique et les exemples sont dans la section « Vérification de la signature du webhook ».

Le changement est rétrocompatible : si vous n'ajoutez pas le contrôle, votre gestionnaire continue de fonctionner comme avant.