Rate Limits

UnifAPI erzwingt zwei Schichten von Rate Limiting: ein Pro-Workspace-Limit, das den Traffic über alle Skills und API-Aufrufe glättet, und ein Pro-Operation-Limit, das jede Public-Data-Quelle schützt.

Header

Jede Antwort — 2xx oder 429 — trägt die Standard-Header:

Wenn sowohl ein Workspace- als auch ein Endpunkt-Limit gilt, melden die Header das jeweils strengere.

Standardwerte

429 behandeln

async function call(url: string, init: RequestInit, attempt = 0): Promise<Response> {
  const res = await fetch(url, init);
  if (res.status !== 429 || attempt >= 5) return res;

  const retryAfter = Number(res.headers.get("Retry-After") ?? 1);
  await new Promise((r) => setTimeout(r, retryAfter * 1000));
  return call(url, init, attempt + 1);
}

Zwei Regeln zum Leben:

1. Beachte Retry-After. UnifAPI gibt die Wartezeit zurück, die die Operation benötigt — Raten macht es meist schlimmer.
2. Backoff bei wiederholten 429s. Wenn ein Skill mehrmals hintereinander das Limit erreicht, verenge die Query, reduziere die Nebenläufigkeit oder erhöhe das Workspace-Limit.

Burst-Verhalten

Limits arbeiten nach dem Token-Bucket-Prinzip: Ein Workspace, der eine Minute lang inaktiv war, kann kurzzeitig über sein Steady-State-Limit hinaus bursten. Verlasse dich darauf nicht für Produktions-Traffic — entwirf für die Steady-State-Rate.

Mehr anfragen

Brauchst du ein höheres Limit? Schreibe an support@unifapi.com mit deiner Workspace-ID, dem Skill oder der Operation, die du ausführst, und einer groben QPS-Schätzung.