Limites de débit et 429

Un appel refusé répond 429 avec un en-tête Retry-After (en secondes entières) et, pour les limites d’appels ci-dessous, deux en-têtes qui donnent les chiffres en vigueur : RateLimit-Policy (pour chaque seau, q la rafale et w les secondes nécessaires pour le remplir) et RateLimit (le seau qui a refusé, et les secondes à attendre). Attendez Retry-After, puis renvoyez le même appel. Nous ne donnons aucun chiffre de débit ni de temps de réponse. Les chiffres ci-dessous sont les valeurs par défaut ; comptez dessus comme un minimum, et lisez les chiffres en vigueur dans les en-têtes d’un 429. Nous pouvons les modifier, avec préavis.

Seau	S’applique à	Défaut
Lectures et gestion, par partenaire	toutes les routes, sauf la création de factures et d’avoirs ; un lot y prend un jeton, puis ses éléments prennent des jetons d’admission	50 par seconde, rafale de 100
Appels à la DGI, par partenaire	création d’un point de vente, remplacement d’un jeton	5 par seconde, rafale de 10
Enregistrement de NIF, par partenaire	`POST /businesses` (il dit si un NIF est connu : il ne doit pas servir à en tester en masse)	2 par seconde, rafale de 10
Admission des factures	`POST …/invoices`, `POST …/credit-notes`, éléments d’un lot	par partenaire et par entreprise, convenue avec vous

Autres limites :

Listes : une page de GET …/invoices ou de GET …/reports demande l’un des quelques créneaux partagés. S’il n’y en a pas un de libre presque aussitôt, la réponse est 429 avec Retry-After: 1. Une page qui met trop longtemps répond 503 QUERY_TIMEOUT : resserrez le filtre (from, to, status). limit vaut 100 au plus sur les listes, 1 000 sur le flux. Un filtre comme ?status=failed sur une très grosse entreprise est le cas coûteux : ajoutez une période.
Fichiers de rapport et exports : deux téléchargements à la fois par partenaire. Au-delà, 429 (EXPORT_DOWNLOADS_BUSY pour les exports) avec Retry-After: 5.
File des rapports : un partenaire peut avoir 1 000 rapports en attente parmi ceux qu’il a demandés, comptés à part pour X et X périodique, et pour Z et A. Le compte des X réunit les rapports X que votre équipe demande dans la console Ripa (origin: "CONSOLE") et les vôtres par cette API. Au-delà, 429 REPORT_QUEUE_FULL avec Retry-After: 60. Les Z automatiques (Rapports) ne sont jamais refusés.
Vérification de l’adresse du webhook : 429 avec Retry-After: 30 quand trop de vérifications sont en cours.
Taille du corps : un corps de plus de 2 Mio répond 413 REQUEST_BODY_TOO_LARGE, le lot ayant ses propres 5 Mio. La plus grande facture, 1 000 lignes, y tient largement.
Un PATCH /businesses/{business} qui fixe un rccm prend sur le même petit seau que POST /businesses, car sa réponse dit si un RCCM est connu. Toute autre modification, non.
Consommation : 92 jours par appel.

Le lot

POST /invoices/batch accepte au plus 100 éléments (sinon 400 BATCH_SIZE_INVALID), 5 Mio et 5 000 lignes de facture au total (413 BATCH_TOO_LARGE). Les éléments peuvent viser des entreprises différentes ; ils sont traités l’un après l’autre, regroupés par entreprise. L’appel répond 200 dès que le corps est lisible, avec un résultat par élément dans l’ordre où vous les avez envoyés, et les totaux accepted, replayed, rejected.

Ne renvoyez que les éléments marqués "retryable": true, chacun avec la même clé qu’avant. Cela couvre un 429, un 500 et un 503 (rien n’a été enregistré, ou le résultat est inconnu et la clé rend la nouvelle tentative sûre). Un élément rejected avec retryable: false est un refus définitif : le renvoyer tel quel donne la même réponse. Corrigez-le d’abord.
Les éléments d’une même entreprise passent ensemble contre la limite de l’entreprise. Un groupe plus grand que cette limite ne passerait jamais, aussi longtemps que vous attendiez, et répond 400 BATCH_LARGER_THAN_BURST avec max_group_size : découpez le lot pour qu’aucune entreprise n’ait plus d’éléments que cela dans un même appel.
Un lot a un budget de temps. Les éléments qui n’avaient pas commencé quand il s’épuise répondent 429 (retryable: true) avec retry_after_seconds.
Refus de l’appel entier : 400 INVALID_JSON, 400 BATCH_SIZE_INVALID, 413 BATCH_TOO_LARGE, et 429 quand trop de corps sont lus en même temps (rien n’a commencé ; renvoyez-le tel quel).