Limite de débit API : en-têtes et réessai après 429

​

Identifiant et exemptions

1. En-tête x-api-key → compteur associé à la clé.
2. Premier saut de X-Forwarded-For → compteur associé à l’IP.
3. REMOTE_ADDR → compteur associé à l’IP.

• La clé interne DIDIT_WEBAPP_API_KEY (utilisée uniquement par la console Didit).
• Les endpoints protégés par l’autorisation IsValidSession (le trafic de session intégré/SDK).
• GET /system/healthcheck (traité par HealthMiddleware en amont de cette pile).
• Les webhooks des fournisseurs : Stripe, filtrage AML, rappels de vérification faciale, modification de listes KYC.

​

Limites globales

​

Limites spécifiques aux endpoints

​

Format de la réponse 429

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1762534870
Retry-After: 37

{
  "detail": "Session creation rate limit exceeded. You can make up to 600 requests per minute."
}

​

Conseils pour les clients

• Respectez Retry-After comme plancher pour votre délai d’attente. Par-dessus, ajoutez une temporisation exponentielle avec gigue (5s → 10s → 20s → 40s ± random) afin que deux clients recevant une réponse 429 au même moment ne se synchronisent pas.
• Arrêtez les tentatives après un nombre limité de tentatives (par ex. 5 tentatives). Renvoyez l’erreur à votre appelant et alertez votre équipe — des erreurs 429 continues indiquent généralement une boucle incontrôlée et non un pic passager.
• Utilisez un identifiant par charge de travail. Partager une x-api-key entre plusieurs backends les rassemble sous le même compteur, ce qui peut amener un voisin bruyant à priver les autres de ressources. Créez une application distincte (et donc une api_key distincte) par environnement, marque ou client — voir Enregistrement programmatique.
• Mettez en cache les lectures de décisions. Les endpoints /decision/ ne sont pas conçus pour des boucles d’interrogation intensives ; si vous avez besoin de mises à jour en temps réel, utilisez les Webhooks et n’appelez GET /v3/session/<id>/decision/ que pour du rattrapage ou de l’audit.
• Générez les PDF hors ligne. Le rendu de PDF consomme beaucoup de CPU (limite de 50/min). Déclenchez-le depuis une file d’attente une fois que la session a atteint un statut terminal, et non à chaque consultation de page.

​

Exemple de client prenant en compte les erreurs 429

async function postSession(body) {
  for (let attempt = 0; attempt < 5; attempt++) {
    const res = await fetch("https://verification.didit.me/v3/session/", {
      method: "POST",
      headers: {
        "x-api-key": process.env.DIDIT_API_KEY,
        "Content-Type": "application/json",
      },
      body: JSON.stringify(body),
    });

    if (res.status !== 429) return res;

    const retryAfter = Number(res.headers.get("Retry-After") ?? "1");
    const jitter = Math.random() * 1000;
    await new Promise((r) => setTimeout(r, retryAfter * 1000 + jitter));
  }
  throw new Error("Didit: too many 429s, giving up");
}

import os
import random
import time

import httpx

def post_session(body: dict) -> httpx.Response:
    with httpx.Client(timeout=15) as client:
        for _ in range(5):
            resp = client.post(
                "https://verification.didit.me/v3/session/",
                headers={
                    "x-api-key": os.environ["DIDIT_API_KEY"],
                    "Content-Type": "application/json",
                },
                json=body,
            )
            if resp.status_code != 429:
                return resp
            wait_s = float(resp.headers.get("Retry-After", "1")) + random.random()
            time.sleep(wait_s)
    raise RuntimeError("Didit: too many 429s, giving up")

​

Besoin d’une marge supérieure ?