Лимиты запросов API: лимиты, заголовки и повтор при 429

​

Идентификатор и исключения

1. Заголовок x-api-key → счётчик, привязанный к ключу.
2. Первый хоп X-Forwarded-For → счётчик, привязанный к IP-адресу.
3. REMOTE_ADDR → счётчик, привязанный к IP-адресу.

• Внутренний DIDIT_WEBAPP_API_KEY (используется только консолью Didit).
• Эндпоинты, защищённые разрешением IsValidSession (трафик встроенных сессий и сессий SDK).
• GET /system/healthcheck (обрабатывается HealthMiddleware до этого стека).
• Webhook’и провайдеров: Stripe, AML-скрининг, callback-вызовы верификации лиц, изменение списков KYC.

​

Глобальные лимиты

​

Лимиты для отдельных endpoint’ов

​

Формат ответа 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."
}

​

Рекомендации для клиента

• Учитывайте Retry-After как минимальную задержку перед повторной попыткой. Поверх неё добавьте экспоненциальную задержку с джиттером (5s → 10s → 20s → 40s ± random), чтобы два клиента, получившие 429 одновременно, не синхронизировались.
• Прекращайте повторные попытки после небольшого предела (например, 5 попыток). Передайте ошибку вызывающему коду и оповестите свою команду: постоянные ответы 429 обычно означают неконтролируемый цикл, а не кратковременный всплеск.
• Используйте один идентификатор на каждую нагрузку. Если один x-api-key используется сразу многими бэкендами, они попадают в один счётчик, и один «шумный» сосед может лишить остальных доступа к лимиту. Создавайте отдельное приложение (а значит, и отдельный api_key) для каждой среды, бренда или клиента. См. Программная регистрация.
• Кэшируйте результаты запросов решений. Endpoint’ы /decision/ не предназначены для частого опроса в тесных циклах. Если нужны обновления в реальном времени, используйте webhook, а GET /v3/session/<id>/decision/ вызывайте только для догрузки данных или аудита.
• Генерируйте PDF офлайн. Рендеринг PDF нагружает процессор и ограничен 50 запросами в минуту. Запускайте его из очереди после того, как сессия перейдёт в конечный статус, а не при каждом просмотре страницы.

​

Пример клиента с обработкой 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")

​

Нужен больший запас?