Aller au contenu principal

Limites de débit

YODI applique les limites de requêtes côté serveur. Les quotas et limites des forfaits sont configurables et peuvent évoluer ; les conditions publiées sont chargées depuis le catalogue dynamique des forfaits. La limite réellement appliquée à un compte peut aussi être personnalisée : le nom d'un forfait ne prouve pas sa limite effective. Crédits, limites de débit et tarifs des opérations sont des contrats distincts.

HTTP 429​

Un refus pour limitation utilise l'enveloppe d'erreur standard YODI. Le serveur peut également fournir l'en-tête de réponse Retry-After et meta.retry_after_ms. Respectez le délai indiqué lorsqu'il est présent ; ne supposez pas l'existence d'en-têtes X-RateLimit-* ou d'une fenêtre de réinitialisation fixe.

interface RateLimitErrorEnvelope {
  error: true;
  status: 429;
  message: "RATE_LIMIT_EXCEEDED";
  data: null;
  meta: {
    request_id: string;
    served_at: string;
    retry_after_ms?: number;
  };
}

Reprises sûres​

  • Pour une lecture idempotente, attendez Retry-After ou meta.retry_after_ms lorsqu'ils sont présents. Sinon, utilisez un backoff exponentiel borné avec jitter.
  • Ne relancez pas automatiquement une opération facturable avec une nouvelle identité. Réutilisez le même Idempotency-Key uniquement si le contrat de la route l'exige et pour réessayer la même opération logique.
  • Limitez le nombre de tentatives et fournissez le request_id au support. Ne traitez pas les erreurs d'authentification, de validation ou les autres erreurs non réessayables comme des limites de débit.

Consultez les tarifs unitaires des opérations pour le catalogue actif et les forfaits publiés pour leurs conditions. La réponse et la consommation réglée par le backend font autorité.