Czy wszystkie moje klucze dzielą jeden limit?

Każdy klucz jest liczony we własnym oknie, a każdy klucz dostaje limit twojego planu. Używaj jednego klucza na aplikację, by zajęta aplikacja nie spowalniała innej.

Czy jest dzienny limit?

Nie. Jedynym limitem jest tempo na minutę. Przy 40 żądaniach na minutę klucz może wykonać do 57 600 żądań dziennie.

Czy żądania obrazów się liczą?

Nie. Obrazy na img.amodb.dev nie wymagają klucza i nie liczą się do twojego limitu.

Limity żądań

Każdy plan ustala limit w żądaniach na minutę: 20, 40 lub 120. amodb liczy żądania w przesuwanym oknie 60 sekund. Każda odpowiedź niesie X-RateLimit-Limit, X-RateLimit-Remaining i X-RateLimit-Reset. Po przekroczeniu limitu dostajesz HTTP 429 z status_code 25 i nagłówek Retry-After w sekundach. Odpowiedzi z cache też się liczą.

Zaktualizowano 18 paź 2026 Zobacz jako Markdown

Limity według planu

Żądania na minutę	Żądania dziennie przy pełnym tempie
20	28 800
40	57 600
120	172 800

Każdy plan obejmuje te same endpointy i dane. Nazwy planów i ceny znajdziesz w cenniku.

Jak działa okno

amodb liczy żądania każdego klucza z ostatnich 60 sekund. Okno się przesuwa: żądanie wykonane o 12:00:30 przestaje się liczyć o 12:01:30. Nie ma zerowania na pełnej minucie, więc stałe tempo sprawdza się lepiej niż serie żądań.

Sprawdzenie klucza i limit żądań działają przed cache na edge. Odpowiedź podana z cache nadal liczy się jako jedno żądanie.

Nagłówki odpowiedzi

Każde wywołanie wykonane z kluczem zwraca te nagłówki:

Nagłówek	Znaczenie
`X-RateLimit-Limit`	Liczba żądań dozwolonych w 60 sekund dla tego klucza.
`X-RateLimit-Remaining`	Liczba żądań pozostałych w bieżącym oknie.
`X-RateLimit-Reset`	Sekundy do chwili, gdy najstarsze liczone żądanie opuści okno.
`Retry-After`	Tylko przy 429: sekundy do odczekania przed następnym wywołaniem.

Gdy osiągniesz limit

Odpowiedzią jest HTTP 429 z treścią błędu TMDB:

JSON

{
  "success": false,
  "status_code": 25,
  "status_message": "Your request count (41) is over the allowed limit of (40)."
}

Poczekaj Retry-After sekund, potem ponów. Nie ponawiaj w ciasnej pętli.

JavaScript Python

jspy

async function amodb(path) {
  for (let attempt = 0; attempt < 3; attempt++) {
    const res = await fetch(`https://api.amodb.dev${path}`, {
      headers: { Authorization: `Bearer ${process.env.AMODB_KEY}` },
    });
    if (res.status !== 429) return res.json();
    const wait = Number(res.headers.get("Retry-After") ?? 1);
    await new Promise((r) => setTimeout(r, wait * 1000));
  }
  throw new Error("amodb: still rate limited after 3 attempts");
}

import os
import time
import requests

def amodb(path):
    for _ in range(3):
        res = requests.get(
            f"https://api.amodb.dev{path}",
            headers={"Authorization": f"Bearer {os.environ['AMODB_KEY']}"},
            timeout=10,
        )
        if res.status_code != 429:
            return res.json()
        time.sleep(int(res.headers.get("Retry-After", "1")))
    raise RuntimeError("amodb: still rate limited after 3 attempts")

Jak zostać poniżej limitu

Zapisuj odpowiedzi w cache po swojej stronie. Szczegóły zmieniają się rzadko; 6 godzin to bezpieczna wartość domyślna.
Użyj append_to_response, by pobrać szczegóły, obsadę i ekipę oraz obrazy jednym żądaniem zamiast trzema.
Rozłóż zadania wsadowe: przy 40 żądaniach na minutę wysyłaj jedno żądanie co 1,5 sekundy.
Odczytuj X-RateLimit-Remaining i zwolnij, zanim dojdzie do 0.