Rate Limits

Все endpoints требуют API Key — анонимный доступ запрещён. Лимиты применяются на конкретный ключ, что позволяет точно отслеживать использование и блокировать abuse.

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

При превышении возвращается HTTP 429 Too Many Requests с заголовком Retry-After: <seconds>.

Per-endpoint лимиты

Чувствительные endpoint'ы имеют дополнительные лимиты:

GET /bookings/lookup-consumer (Find my trip)

• 3 запроса/мин на IP + 10 запросов/час
• Защита от brute-force подбора PNR + email

POST /bookings/

• 30 запросов/мин на B2B-ключ
• Защита от случайных дублей

Mutations через publishable key

• pk_* ключи не могут делать mutations (создание / изменение / отмена)
• Только catalog reads + POST /bookings/ с известным passenger_id (для consumer flow)

Кеширование на стороне клиента

Каталог (airports, routes, fare-families, baggage rules) меняется редко. Рекомендуем кешировать у себя на 5-30 минут — это снимет давление на rate limit и ускорит UX.

API уже использует ETag — присылайте If-None-Match чтобы получать 304 Not Modified без расхода квоты.

Авторизованные endpoints (bookings, payments) не кешируются — всегда возвращают актуальные данные.

Best practices

• При 429 — exponential backoff с jitter (1s, 2s, 4s ± 200ms)
• Кешируйте справочники (airports, routes) на стороне клиента
• Не делайте polling чаще 1 раза в 30 секунд для статусов рейсов
• Для batch-операций используйте specialized endpoints
• Используйте pk_* для frontend — у него самый мягкий per-key лимит, чтобы не блокировать пользователей при всплесках

Ответ при rate limit

HTTP/1.1 429 Too Many Requests
Retry-After: 12
Content-Type: application/json

{
  "detail": "Слишком много запросов. Повторите через 12 секунд."
}

Хочу больше квоты

Свяжитесь с partners@nurcore.kg — для B2B с подтверждённым объёмом операций возможно повышение лимитов.