# Erreur WhatsApp 131056 : limite par destinataire URL: https://wa.genuka.com/docs/errors/131056 Language: French > Erreur WhatsApp 131056 : trop de messages au même destinataire en peu de temps. La limite par paire (1 message toutes les 6 s) et comment réessayer. L'erreur WhatsApp 131056 signifie que vous avez envoyé trop de messages au même destinataire en trop peu de temps : Meta autorise en régime normal un message toutes les 6 secondes par paire expéditeur-destinataire. Attendez avant de réécrire à cette personne ; vos envois vers d'autres numéros, eux, peuvent continuer sans pause. ## Que signifie l'erreur 131056 ? > « Too many messages sent from the sender phone number to the same recipient phone number in a > short period of time. » > — [Meta, codes d'erreur de la Cloud API](https://developers.facebook.com/documentation/business-messaging/whatsapp/support/error-codes#throttling-errors) Meta conseille d'attendre puis de réessayer si vous tenez à écrire à ce numéro, et rappelle que vous pouvez écrire à un **autre** numéro sans attendre. La règle derrière ce code est la **limite par paire** (*pair rate limit*) ([Meta, About the platform](https://developers.facebook.com/documentation/business-messaging/whatsapp/about-the-platform#rate-limits)) : | Règle | Valeur | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | Rythme normal vers un même destinataire | 1 message toutes les 6 secondes (0,17 message/s) | | Équivalent | environ 10 messages par minute, 600 par heure | | Rafale tolérée | jusqu'à 45 messages en 6 secondes, empruntés sur le quota à venir | | Après une rafale | attendre le temps qu'auraient pris ces messages au rythme normal : une rafale de 20 demande environ 2 minutes | | Réessai recommandé par Meta | après 4^X secondes, X partant de 0 et augmentant de 1 à chaque échec | ## Quand l'erreur 131056 apparaît-elle ? * **Un doublon dans une liste de campagne.** Genuka WA ne dédoublonne pas les destinataires d'une campagne : le même numéro présent deux fois reçoit deux envois consécutifs. * **Un bot qui découpe sa réponse** en cinq ou six bulles envoyées d'affilée. * **Un bouton « Renvoyer le code »** sans délai minimal entre deux clics. * **Un traitement de webhook non idempotent** qui répond à chaque relivraison du même message entrant. Les webhooks Genuka WA peuvent arriver en double : dédoublonnez sur `X-Genuka-Delivery` ou sur le `wamid`. ### Où la voir dans Genuka WA ? | Canal | Ce que vous recevez | | ---------------------------------- | ---------------------------------------------------------------------------------- | | Réponse de `POST /api/v1/messages` | `400`, `"error": "send_retryable"`, `meta.code: 131056`, `meta.retryable: true` | | Campagne | Le destinataire est réessayé, puis passe `failed` si les trois tentatives échouent | | Tableau de bord, section Journaux | La requête refusée et le corps de la réponse | Un détail compte pour les campagnes : les trois tentatives du lanceur s'enchaînent en moins de deux secondes (attentes de 500 ms puis 1 s au plus), moins que les 6 secondes de la limite par paire. Un doublon dans la liste finit donc généralement en `failed`. La correction est de dédoublonner en amont, pas d'allonger les tentatives. ## Comment corriger l'erreur 131056 ? 1. **Arrêtez d'écrire à ce destinataire pour le moment**, et continuez normalement avec les autres. 2. **Réessayez avec le calendrier de Meta** : 1 s, puis 4 s, puis 16 s, puis 64 s. 3. **Espacez les envois par destinataire** : une file par numéro, avec au moins 6 secondes entre deux messages. **Node.js** ```ts const API = "https://wa.genuka.com/api/v1"; const PAIR_GAP_MS = 6_000; const lastSentTo = new Map(); // à déplacer dans Redis si vous avez plusieurs workers async function send(payload: { connectionId: string; to: string } & Record) { const response = await fetch(`${API}/messages`, { method: "POST", headers: { Authorization: `Bearer ${process.env.GENUKA_WA_API_KEY}`, "Content-Type": "application/json", }, body: JSON.stringify(payload), }); return { response, json: await response.json() }; } export async function sendToRecipient(payload: { connectionId: string; to: string } & Record) { // 1. Respecter l'écart minimal vers ce destinataire. const wait = (lastSentTo.get(payload.to) ?? 0) + PAIR_GAP_MS - Date.now(); if (wait > 0) await new Promise((resolve) => setTimeout(resolve, wait)); // 2. Sur 131056, réessayer après 4^X secondes : 1 s, 4 s, 16 s, 64 s, soit cinq tentatives. for (let x = 0; x <= 4; x++) { const { response, json } = await send(payload); lastSentTo.set(payload.to, Date.now()); if (response.ok) return json.data; if (json.meta?.code !== 131056) throw new Error(`${json.error}: ${json.message ?? ""}`); if (x === 4) break; // pas d'attente après la dernière tentative await new Promise((resolve) => setTimeout(resolve, 4 ** x * 1_000)); } throw new Error("131056: destinataire toujours limité, à replanifier"); } ``` **Python** ```python import os import time import requests API = "https://wa.genuka.com/api/v1" HEADERS = { "Authorization": f"Bearer {os.environ['GENUKA_WA_API_KEY']}", "User-Agent": "acme-crm/1.0 (+https://example.com)", } PAIR_GAP = 6.0 last_sent_to: dict[str, float] = {} # à déplacer dans Redis si vous avez plusieurs workers def send_to_recipient(payload: dict) -> dict: wait = last_sent_to.get(payload["to"], 0) + PAIR_GAP - time.time() if wait > 0: time.sleep(wait) for x in range(5): # cinq tentatives, avec 1 s, 4 s, 16 s, 64 s entre elles response = requests.post(f"{API}/messages", json=payload, headers=HEADERS, timeout=30) last_sent_to[payload["to"]] = time.time() body = response.json() if response.ok: return body["data"] if body.get("meta", {}).get("code") != 131056: raise RuntimeError(f"{body.get('error')}: {body.get('message', '')}") if x == 4: break # pas d'attente après la dernière tentative time.sleep(4 ** x) raise RuntimeError("131056: destinataire toujours limité, à replanifier") ``` ## Comment éviter l'erreur 131056 ? * **Dédoublonnez vos listes avant `POST /api/v1/campaigns`**, sur le numéro normalisé (chiffres seuls, avec indicatif) : `+237 690 00 00 01` et `237690000001` sont le même destinataire. * **Regroupez vos bulles.** Un message de 4 096 caractères au plus vaut mieux que cinq messages courts envoyés d'affilée. * **Mettez un délai minimal sur les renvois de code**, 30 à 60 secondes, ce qui protège aussi vos utilisateurs contre les abus. * **Rendez le traitement des webhooks idempotent**, pour qu'une relivraison ne déclenche jamais une seconde réponse. ## Quels codes sont liés ? * [130429](https://wa.genuka.com/docs/errors/130429) : le débit **global** du numéro est atteint, tous destinataires confondus. * [131048](https://wa.genuka.com/docs/errors/131048) : envois restreints pour cause de signalements ; insister vers un même destinataire n'aide pas. ## FAQ ### L'erreur 131056 bloque-t-elle mes envois vers les autres clients ? Non. Meta le précise : vous pouvez continuer à écrire à d'autres numéros sans attendre. Seule la paire expéditeur-destinataire concernée est freinée. ### Combien de messages puis-je envoyer à un même client par heure ? En régime continu, environ 600, soit un toutes les 6 secondes. Une rafale de 45 messages en 6 secondes est tolérée, mais elle se paie ensuite par une attente équivalente. ### Faut-il un délai fixe ou croissant pour réessayer ? Croissant. Meta recommande 4^X secondes, X partant de 0 : 1 s, 4 s, 16 s, 64 s. Un délai fixe court renvoie la requête alors que la limite est toujours active. ## Sources * [Meta — Error codes](https://developers.facebook.com/documentation/business-messaging/whatsapp/support/error-codes) * [Meta — About the platform, pair rate limits](https://developers.facebook.com/documentation/business-messaging/whatsapp/about-the-platform#rate-limits) * [Meta — Throughput](https://developers.facebook.com/documentation/business-messaging/whatsapp/throughput)