Warteschlange und Limits

WarteschlangeCopy Anchor Link

• Pro Konto werden bis zu 10 Jobs gleichzeitig verarbeitet.
• Dahinter warten bis zu 30 Jobs in der Warteschlange. Solange ein Job wartet, liefert GET /edits/{id} seine queue_position (Jobs, die vor ihm warten; laufende Jobs zählen nicht, 0 heißt also, er startet als Nächster) und estimated_seconds (unsere Schätzung, wann er fertig ist).
• Warten bereits 30 Jobs, liefert POST /edits 503 queue_full mit einem Retry-After-Header. Es wird nichts berechnet.
• Ein Job kann nach Verlassen der Warteschlange bis zu 10 Minuten laufen. Wartezeit zählt nicht mit, bei voller Warteschlange kann der letzte Job im ungünstigsten Fall also etwa 30 Minuten dauern. Die meisten Jobs sind in 1–2 Minuten fertig, 9 von 10 in 3 Minuten.

Rate-LimitsCopy Anchor Link

Jedes Konto – geteilt von all seinen Schlüsseln – kann in jedem gleitenden 60-Sekunden-Fenster Folgendes senden:

Jede Anfrage mit gültigem Schlüssel zählt, auch Anfragen, die mit einem Fehler abgelehnt werden. Anfragen ohne oder mit ungültigem Schlüssel zählen für kein Konto.

Bei Überschreitung kommt 429 rate_limited mit Retry-After, immer in ganzen Sekunden: die Zeit, bis die älteste Anfrage im Fenster verfällt. GET /account liefert Ihre aktuellen Limits in limits. Enterprise-Konten können höhere Limits haben.

PollingCopy Anchor Link

• Solange ein Job processing ist oder queued mit queue_position 0, fragen Sie GET /edits/{id} alle 5 Sekunden ab.
• Solange er weiter hinten queued ist, sehen Sie alle 30 Sekunden nach. estimated_seconds gibt an, wann der Job fertig sein sollte, nicht wann Sie nachsehen sollen.

Mit 10 laufenden und 30 wartenden Jobs sind das höchstens 190 Abfragen pro Minute, innerhalb des Limits von 240. Um gar nicht abzufragen, übergeben Sie callback_url und empfangen einen Webhook.

BilderCopy Anchor Link

• JPEG, PNG oder WebP, bis 20 MB, längste Seite bis 8000 px.
• Senden Sie es als image_url, image_base64, Multipart-Datei image oder als image_id aus einem früheren OCR-Aufruf – genau eines davon pro Anfrage.
• Bis zu 20 Ersetzungen pro Bearbeitung.

Wie Sie jede Upload-Methode kodieren, EXIF, Transparenz und die Ergebnisdateien beschreibt Bilder.

Sichere WiederholungenCopy Anchor Link

Senden Sie bei jedem POST /edits einen Idempotency-Key-Header, damit Sie nach einem Timeout oder Netzwerkfehler gefahrlos wiederholen können. Wird derselbe Schlüssel innerhalb von 24 Stunden erneut verwendet, kommt 202 mit der id des ursprünglichen Jobs und seinem aktuellen Status (er kann bereits processing oder fertig sein) – statt einen neuen Job anzulegen und zu berechnen, selbst wenn der Body abweicht. Schlüssel gelten pro Konto und werden von all seinen API-Schlüsseln geteilt. Eine abgelehnte Anfrage (jedes 4xx oder 5xx) verbraucht ihren Schlüssel nicht, Sie können sie also nach der Korrektur mit demselben Schlüssel erneut senden.