Ratenlimits

Die öffentliche API wendet auf jeden API-Schlüssel und jedes OAuth-Zugriffstoken ein gleitendes Anfragekontingent von einer Minute an. Das Erstellen weiterer Schlüssel, um ein Limit zu umgehen, wird nicht unterstützt und kann zu Einschränkungen von Zugangsdaten oder Konten führen.

Tariflimits#

Zugangsdaten, deren Konto keinen aktiven kostenpflichtigen Tarif hat, erhalten 403 subscription_required, bevor Ratenlimit-Kapazität zugewiesen wird. Make Agent Fast kann für ungewöhnlich aufwendige Vorgänge niedrigere endpunktspezifische Limits einführen; in diesem Fall werden sie in der Endpunkt-Referenz ausdrücklich genannt.

Eine Antwort bei überschrittenem Ratenlimit#

Ist das Kontingent erschöpft, gibt die API 429 rate_limit_exceeded zurück, und zwar mit:

HTTP/1.1 429 Too Many Requests
Retry-After: 17
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 0
X-Request-Id: 6c0b2f2e-...
Content-Type: application/json

Retry-After gibt die Mindestanzahl an Sekunden an, die Sie warten müssen. Jede authentifizierte Antwort enthält außerdem X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset (ein Unix-Zeitstempel), sodass Anwendungen ihre Anfragen drosseln können, bevor ein 429 auftritt.

Wiederholungslogik implementieren#

Verwenden Sie exponentielles Backoff mit zufälligem Jitter, berücksichtigen Sie einen größeren Retry-After-Wert und begrenzen Sie die Gesamtzahl der Versuche.

async function requestWithRetry(url: string, init: RequestInit, attempts = 4) {
  for (let attempt = 0; attempt < attempts; attempt += 1) {
    const response = await fetch(url, init);
    if (response.status !== 429 && response.status < 500) return response;

    if (attempt === attempts - 1) return response;
    const retryAfter = Number(response.headers.get("retry-after") ?? 0) * 1_000;
    const exponential = 500 * 2 ** attempt;
    const jitter = Math.random() * 250;
    await new Promise((resolve) =>
      setTimeout(resolve, Math.max(retryAfter, exponential + jitter)),
    );
  }
  throw new Error("unreachable");
}

Verwenden Sie bei POST, PATCH und DELETE bei jeder Wiederholung nach einem Netzwerk- oder Serverfehler denselben gültigen Idempotency-Key. Ein neuer Idempotency-Key kann dazu führen, dass ein bereits abgeschlossener Seiteneffekt erneut ausgeführt wird.

Anfragevolumen reduzieren#

• Cachen Sie Lesezugriffe auf Konto-, Website- und Konfigurationsdaten, die nicht in Echtzeit aktuell sein müssen.
• Fordern Sie bis zu 100 Datensätze pro Seite an, statt wiederholt sehr kleine Seiten abzurufen.
• Verarbeiten Sie Webhook-Ereignisse, statt Conversations, Leads oder Broadcasts per Polling abzufragen.
• Begrenzen Sie die Worker-Parallelität pro API-Schlüssel; ein Burst aus vielen Serverless-Aufrufen teilt sich dasselbe Kontingent.
• Verwenden Sie separate Schlüssel für separate Dienste, um Isolation und Nachvollziehbarkeit zu erreichen – nicht, um die Kapazität einer einzelnen Workload zu vervielfachen.

Tabelle: Wiederholen oder nicht wiederholen#

Wenn eine dauerhafte Workload ihr Tarifkontingent berechtigterweise überschreitet, reduzieren Sie das Polling, bündeln Sie Aufgaben oder wenden Sie sich mit repräsentativen Anfrage-IDs und dem erwarteten Datenverkehr an den Support, anstatt eine unbegrenzte Wiederholungsschleife einzubauen.