Limites de débit

L'API publique applique un compteur de requêtes sur une minute glissante à chaque clé API ou jeton d'accès OAuth. Créer davantage de clés pour contourner une limite n'est pas pris en charge et peut entraîner des restrictions sur vos identifiants ou votre compte.

Limites par forfait#

Un identifiant dont le compte n'a aucun forfait payant actif reçoit une erreur 403 subscription_required avant que toute capacité de débit ne lui soit accordée. Make Agent Fast peut introduire des limites plus basses, propres à certains endpoints, pour les opérations particulièrement coûteuses ; le cas échéant, la référence de l'endpoint les indiquera explicitement.

Une réponse limitée en débit#

Lorsque le quota est épuisé, l'API renvoie 429 rate_limit_exceeded avec :

HTTP/1.1 429 Too Many Requests
Retry-After: 17
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 0
X-Request-Id: 6c0b2f2e-...
Content-Type: application/json

Retry-After indique le nombre minimal de secondes à attendre. Chaque réponse authentifiée inclut également X-RateLimit-Limit, X-RateLimit-Remaining et X-RateLimit-Reset (un horodatage Unix), ce qui permet aux applications de limiter leur débit avant d'obtenir une erreur 429.

Implémenter les nouvelles tentatives#

Utilisez un backoff exponentiel avec un jitter aléatoire, respectez une valeur de Retry-After plus élevée et plafonnez le nombre total de tentatives.

async function requestWithRetry(url: string, init: RequestInit, attempts = 4) {
  for (let attempt = 0; attempt < attempts; attempt += 1) {
    const response = await fetch(url, init);
    if (response.status !== 429 && response.status < 500) return response;

    if (attempt === attempts - 1) return response;
    const retryAfter = Number(response.headers.get("retry-after") ?? 0) * 1_000;
    const exponential = 500 * 2 ** attempt;
    const jitter = Math.random() * 250;
    await new Promise((resolve) =>
      setTimeout(resolve, Math.max(retryAfter, exponential + jitter)),
    );
  }
  throw new Error("unreachable");
}

Pour POST, PATCH et DELETE, conservez la même clé Idempotency-Key valide à chaque nouvelle tentative, qu'elle fasse suite à une erreur réseau ou serveur. Une nouvelle clé d'idempotence peut répéter un effet de bord déjà exécuté.

Réduire le volume de requêtes#

• Mettez en cache les lectures de compte, de site et de configuration qui n'exigent pas une fraîcheur en temps réel.
• Demandez jusqu'à 100 enregistrements par page plutôt que de solliciter à répétition de très petites pages.
• Traitez les événements de webhook au lieu d'interroger régulièrement les conversations, les leads ou les diffusions.
• Limitez la concurrence des workers par clé API : une rafale provenant de nombreuses invocations serverless partage le même compteur.
• Utilisez des clés distinctes pour des services distincts afin d'assurer l'isolation et la traçabilité, et non pour multiplier la capacité d'une même charge de travail.

Tableau des réponses à retenter ou non#

Si une charge de travail soutenue dépasse légitimement le quota de son forfait, réduisez l'interrogation régulière, regroupez les traitements ou contactez le support en fournissant des identifiants de requête représentatifs et le trafic attendu, plutôt que d'ajouter une boucle de nouvelles tentatives sans limite.