On this page

Impressum · Datenschutzerklärung · Allgemeine Geschäftsbedingungen · Drittsoftware · Lizenzbedingungen (EULA) · SaaS-Bedingungen · Fair-Use-Regeln · Service Levels · Auftragsverarbeitungsvertrag · Technische und organisatorische Maßnahmen
Read in English (Fair use): Übersetzung, maßgeblich ist dieser deutsche Text

Version 2026-11-08

Diese Seite beschreibt, was wir bei der Nutzung des von uns gehosteten Dienstes (der API von ocr-software.com) als fair ansehen und was wir tun, wenn jemand die Grenzen überschreitet. Sie ist Teil der SaaS-Bedingungen. Für das Paket auf Ihrem eigenen Server gilt sie nicht; dort gelten die Lizenzbedingungen. Sie ist keine Zusage, dass der Dienst bereitsteht (SaaS-Bedingungen Ziff. 2).

1. Der Grundsatz

Der Dienst teilt sich eine begrenzte Rechenleistung. Fair ist eine Nutzung, die andere Nutzer nicht verdrängt, den Dienst nicht gefährdet und dem Zweck entspricht, für den es ihn gibt: Texterkennung für Dokumente, an denen Sie die Rechte haben.

2. Was fair ist

  • Sie lesen eigene Dokumente und Testseiten, auch viele, in einem Takt, den die Grenzen in Ziffer 3 tragen.
  • Sie beachten die Antwort 429 und warten die Zeit ab, die Retry-After nennt, bevor Sie es wieder versuchen.
  • Sie nutzen einen Schlüssel für ein Unternehmen oder ein Vorhaben und geben ihn nicht weiter.
  • Sie bauen die API in Ihre Anwendungen ein. Dienste für Ihre eigenen Kunden, in denen die OCR ein Teil ist, sind in Ordnung.

3. Technische Grenzen

Diese Grenzen gelten je Bestellung, soweit nicht anders vermerkt: Haupt- und Unter-Schlüssel einer Bestellung zählen zusammen, damit mehr Schlüssel nicht mehr Last bedeuten. Für Gratis-Schlüssel gilt zusätzlich eine Grenze je Netz (IPv4 /24, IPv6 /64), damit sich nicht viele kostenlose Bestellungen aus einem Netz zu einer Last addieren; bezahlte Bestellungen begrenzt das Netz nicht. Antwortet der Dienst mit 429, nennt das Fehlerobjekt die Grenze, die gegriffen hat (unter limit), ihren Wert und den Stand; der Text sagt, ob es „this key“, „this order“ oder „this network“ war.

Grenze Wert Name im Fehlerobjekt
Anfragen je Sekunde 20, kurzzeitig bis 40 requests_per_second
gleichzeitig laufende Aufträge 8 max_jobs_per_key
gleichzeitige Uploads 2 Fehlercode too_many_uploads
gleichzeitig bearbeitete Anfragen im ganzen Dienst 64 max_in_flight
Statusabfrage (GET /v1/status) und Katalog (GET /v1/catalog), je Adresse 60 per minute, kurzzeitig bis 20 status_per_minute
Größe einer Anfrage 100 MiB
Seiten je Dokument 1,000
Pixel je gerenderter Seite 40 million
Abrufdauer eines Ergebnisses 24 hours

Beim Namen max_jobs_per_key (alle Aufträge der Bestellung sind unfertig, auch Uploads zählen mit): Holen Sie zuerst das Ergebnis eines fertigen Auftrags ab oder warten Sie, bis einer fertig ist, und senden Sie dann neu; Retry-After nennt nur, wann Sie es frühestens wieder versuchen können. Die Statusabfrage ist für Monitoring gedacht, aber nicht im Sekundentakt von vielen Stellen aus derselben Adresse; fragen Sie lieber im Abstand, den die Grenze trägt.

Ein Upload ist der Aufruf POST /v1/jobs, der Ihre Datei überträgt: vom ersten Byte, bis der Dienst das Dokument geprüft hat (Typ, Größe, Seitenzahl) und mit der Auftrags-ID antwortet. Dieser Zeitraum belegt einen Upload-Platz, weil die Datei in dieser Zeit im Zwischenspeicher des Dienstes liegt und der Platz dort knapp ist; darum läuft je Bestellung nur 2 Upload gleichzeitig, und im ganzen Dienst höchstens 8. Mit der Auftrags-ID beginnt der Auftrag; er zählt nicht mehr als Upload, sondern wartet in unserer Warteschlange, bis er an der Reihe ist. Darum sind 8 Aufträge gleichzeitig möglich, auch wenn nur 2 Dateien zugleich unterwegs sein dürfen. Senden Sie also nicht mehr Dateien gleichzeitig, als die Tabelle erlaubt, und holen Sie die Ergebnisse über die Auftrags-ID ab.

Ein dritter gleichzeitiger Upload bekommt 429 (too_many_uploads); ist der Dienst insgesamt ausgelastet, bekommt er 503 (busy). Jedes 429 und jedes 503 busy trägt Retry-After mit der Zeit in Sekunden; warten Sie diese Zeit ab und wiederholen Sie dann.

Wir können diese Werte ändern, etwa wenn die Last es verlangt. Ein Vertrag mit uns kann höhere Werte vorsehen.

4. Dateien und Ergebnis

Diese Grenzen schützen den Zwischenspeicher und den Arbeitsspeicher des Dienstes und halten jedes Ergebnis prüfbar.

  • Erlaubte Typen: PDF, PNG, JPEG and TIFF. Kein BigTIFF, keine Archive.
  • Größe: höchstens 100 MiB je Datei; bei einem PDF höchstens 10 MiB je Seite (Dateigröße geteilt durch Seitenzahl); bei einem Bild oder einer TIFF-Seite höchstens 10 MiB; höchstens 1,000 Seiten je Dokument. Ein größeres Dokument teilen Sie selbst und schicken die Teile als getrennte Aufträge.
  • Übertragung: Ein Upload muss im Mittel mindestens 128 KiB/s erreichen, nach einer Anlaufzeit von 15 seconds, die auch für die längste einzelne Pause gilt. Langsamere Uploads bekommen 408 (upload_too_slow), damit ein hängender Upload nicht einen der wenigen Plätze festhält.
  • Prüfung: Muss die Prüfung eines Dokuments länger als 20 seconds auf einen freien Platz warten, bekommt der Upload 503 (busy) mit Retry-After.
  • Auflösung (dpi) beim Rendern eines PDF: 150, 200 or 300 (Standard 150); jeder andere Wert, auch 600, ergibt 400 (invalid_dpi).
  • Zeit: Eine Seite darf höchstens 60 seconds rendern, ein ganzes Dokument höchstens 30 minutes; die Pixelgrenze je Seite steht in Ziffer 3.
  • Ergebnis: höchstens 20,000 Zeilen je Seite, 2,000 Wörter je Zeile und 2,000 Layoutbereiche je Seite; Wörter über 1,000 Zeichen werden gekürzt. Es werden höchstens 50 Tabellen je Seite erkannt; eine Tabelle hat höchstens 500 Zeilen oder Spalten, 250,000 Zeilen mal Spalten, 20,000 Zellen und 2,000 Wörter je Zelle. Überschreitet eine Seite eine dieser Grenzen, ist diese eine Seite failed, nie das ganze Dokument.

5. Aufträge und Abfragen

Diese Grenzen machen Wiederholungen sicher und halten das Abfragen leicht.

  • Idempotency-Key: bis 255 Zeichen, gültig 24 hours; client_ref: bis 200 Zeichen.
  • Long Polling (wait): höchstens 60 seconds; ein größerer Wert ist ein Fehler.
  • Auftragsliste: ohne Angabe 100 Einträge je Seite, höchstens 1,000.
  • Bestellung: bis zu 50 Schlüssel je Bestellung.

6. S3-Bucket

Ein Lauf liest ein Objekt nach dem anderen, damit er andere Nutzer nicht verdrängt; die Beschränkung auf öffentliche Adressen schützt unser Netz.

  • Jedes S3-kompatible Bucket, nur über https, nur mit öffentlichen Adressen, ohne Weiterleitung.
  • Die Quelle darf nur dann anonym gelesen werden, wenn Sie das ausdrücklich setzen. Das Ziel braucht immer Schlüssel.
  • Vor dem Start listet der Dienst den Quellordner bis zum ersten Objekt (15 seconds); falsche Zugangsdaten oder ein unerreichbares Bucket scheitern sofort mit 422, es startet kein Lauf. Die Anfrage selbst ist höchstens 64 KiB groß, die Auftrags-ID hat 1 bis 64 Zeichen.
  • Quell- und Zielordner dürfen sich nicht überlappen. Presigned-URLs werden nicht angenommen.
  • Was gelesen wird: Objekte mit der Endung .pdf (Groß- und Kleinschreibung egal). Alle anderen Objekte, etwa Bilder oder TIFF, werden beim Auflisten übersprungen: nicht gelesen, nicht gezählt, nicht im Manifest. Ein Objekt mit der Endung .pdf, das kein PDF ist, wird als failed mit unsupported_type ins Manifest eingetragen; die übrigen Objekte laufen weiter. Ein gemischtes Bucket ist also möglich, aber nur die PDF werden erkannt.
  • Was im Zielordner liegt: je Objekt eine Datei je gewähltem Format, Name <Zielordner><Pfad ab Quellordner><Endung> mit der Endung .json, .txt, .md, .hocr oder .pdf (a/b.pdf wird zu a/b.pdf.json, so kollidieren x.pdf und x.PDF nie). Ein Ausgabeschlüssel über 1,000 Zeichen macht dieses Objekt failed (output_key_too_long). Dazu manifest.json: Job, Pipeline, Formate, Status (complete oder incomplete), Stopgrund und je Objekt Schlüssel, ETag, Größe, Status (done, partial, failed), Seitenzahlen, Fehlercode und Ausgabedateien. Es enthält nur Namen und Zahlen, nie Inhalt, und wird alle 20 Objekte sowie bei Stopp, Abbruch und Ende geschrieben.
  • Zweiter Lauf auf dasselbe Ziel: Mit derselben Auftrags-ID setzt der Dienst über das Manifest fort. Objekte, die fertig sind oder endgültig scheiterten und denselben ETag haben, werden nicht noch einmal gelesen; Objekte mit vorübergehendem Fehler (store_error, gone, timeout, internal_error) und nicht gelaufene Seiten werden wiederholt; ein geänderter ETag lässt das Objekt neu laufen. Fertige Seiten werden nicht doppelt berechnet. Liegt im Zielordner das Manifest eines anderen Auftrags, einer anderen Pipeline oder anderer Formate, scheitert der Lauf mit output_prefix_conflict und überschreibt nichts. Ist das Manifest verloren, läuft alles neu, aber ohne Doppelbuchung.
  • Grenze je Lauf: höchstens 100,000 Objekte und 30 minutes je Objekt. Gezählt werden die .pdf-Objekte in der Reihenfolge der Auflistung (S3 liefert sie nach Schlüssel), auch die schon fertigen. Beim ersten Objekt über der Grenze stoppt der Lauf hart: es wird nichts mehr gelesen, alles davor ist fertig und abgerechnet, das Manifest steht auf incomplete mit dem Stopgrund max_objects, und die Statusabfrage zeigt incomplete. Für den Rest brauchen Sie einen neuen Lauf mit einem Quellordner, der nur die übrigen Objekte enthält (etwa ein Unterordner); derselbe Quellordner endet wieder bei der Grenze.

7. Gratis-Test

Der Gratis-Test auf /try/ lässt Besucher ohne Konto eine Seite ausprobieren, ohne zahlende Nutzer zu verdrängen.

  • Eine Seite je Aufruf, als PNG oder JPEG, höchstens 32 MiB.
  • Höchstens 6 Seiten je Minute und Adresse. Ist der Test ausgelastet, bekommen Sie 503 (busy) mit Retry-After.
  • Die Seite wird nach dem Lesen gelöscht.

8. Aufbewahrung

Wir halten Daten nicht länger, als wir müssen oder versprochen haben.

  • Ein fertiges Ergebnis bleibt 24 hours abrufbar (Ziffer 3).
  • Buchungen (Seiten und Beträge, nie Inhalt) bewahren wir ten years ab Ende des Buchungsjahres auf, weil das Handelsrecht es verlangt.
  • Volle Client-Adressen bewahren wir 7 days auf; die Zähler je Netz halten nur den Netzbereich, nicht die Adresse (Fenster 30 days, Ziffer 10).
  • Der Bestätigungslink aus der Bestell-Mail gilt one hour; Sie bekommen ihn selbst. Der Portal-Link ist ein anderer: Ihn stellt unser Support aus, er gilt standardmäßig 24 hours, höchstens seven days.
  • Eine Anfrage ohne Vertrag bewahren wir 183 days (six months) auf.

9. Was nicht fair ist

  • Mehrere Schlüssel, Konten, Adressen oder Netze zu nutzen, um die Grenzen zu umgehen.
  • Den Dienst als eigene OCR-Schnittstelle weiterzuverkaufen (ein Zugang gegen Entgelt, der im Kern aus unserer API besteht).
  • Dauerlast ohne Absprache, die andere Nutzer spürbar ausbremst.
  • Versuche, Modelle oder Gewichte auszulesen, Schadsoftware zu senden oder den Dienst zu überlasten.
  • Eine Nutzung, die gegen Gesetz verstößt, auch gegen Sanktions- und Exportrecht.

10. Was wir tun

  • Reihenfolge: Seiten von Nutzern ohne Zahlung können hinter Seiten von Nutzern mit Zahlung warten. Wir streben höchstens one hour an; zugesagt ist die Zeit nicht.
  • Grenze je Netz: Für Nutzer ohne Zahlung gilt zusätzlich eine Grenze je Netz (IPv4 /24, IPv6 /64) in einem Fenster von 30 days. Ihre Höhe nennen wir nicht.
  • Drosseln und sperren: Bei heftiger oder unfairer Nutzung dürfen wir einen Schlüssel drosseln, die Annahme weiterer Seiten zeitweise begrenzen oder den Schlüssel sperren. Daraus entsteht keine Zahlungspflicht. Wir teilen es mit, wenn wir drosseln, soweit uns eine Adresse vorliegt, und nennen den Grund, soweit das den Missbrauchsschutz nicht schwächt.
  • Keine feste Seitenzahl: Eine Zahl von Seiten, die ohne Zahlung gelesen werden dürfen, nennen und sagen wir nicht zu.

11. Mehr brauchen

Wer mehr Durchsatz oder mehr Verlässlichkeit braucht, schreibt an info@ocr-software.com. Wir bieten dann einen Vertrag an: höhere Grenzen, einen eigenen Server oder das Paket zum produktiven Einsatz. Was dort steht, geht dieser Seite vor.