Limity zapytań

Limity są liczone na klucz API, w stałych oknach jednominutowych.

Kubełki są niezależne — wyczerpanie zapisów nie blokuje odczytów. Okno jest stałe, nie przesuwne: licznik zeruje się na pełnej minucie, a nie 60 sekund po Twoim pierwszym żądaniu.

Co dostajesz po przekroczeniu

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

{
  "error": {
    "code": "RATE_LIMITED",
    "message": "Przekroczono limit zapytań. Ponów po wskazanym czasie.",
    "details": { "retryAfterSeconds": 23 }
  }
}

Retry-After to liczba sekund do zamknięcia bieżącego okna, więc nigdy nie przekracza 60. Ta sama wartość siedzi w details.retryAfterSeconds.

curl -si https://app.mediflo.ai/api/external/v1/bots \
  -H "Authorization: Bearer mflo_live_..." \
  | grep -i '^HTTP/\|^retry-after:'

Jak się dostroić

• Honoruj Retry-After. Odczekaj tyle, ile mówi nagłówek, zamiast ponawiać od razu — natychmiastowa powtórka trafi w to samo okno.
• Wykładnicze odczekanie dla 429, 502, 503 i 500. Kody 4xx poza 429 nie przejdą same z siebie; nie ponawiaj ich.
• Jeden klucz na integrację. Limit jest na klucz, więc dwie integracje na jednym kluczu jedzą sobie nawzajem budżet, a Ty nie widzisz w dzienniku audytu, która.
• Bierz duże strony. limit=100 zamiast limit=10 to dziesięć razy mniej żądań na ten sam zestaw danych. Patrz Paginacja.
• Cachuj to, co rzadko się zmienia. Lista tagów zmienia się rzadko, lista użytkowników umiarkowanie, zadania często.
• Webhooki zamiast odpytywania. Jeśli czekasz na wynik rozmowy, subskrybuj bot_call.completed zamiast pytać GET /bot-sessions w pętli. Patrz Webhooki.