Ein n8n-Workflow zum Dokumentenscannen, der an der Kamera beginnt

Die meisten n8n-Anleitungen zum Dokumentenscannen beginnen an einer Stelle, die es in der Praxis nicht gibt: bei einer Datei, die schon ordentlich irgendwo liegt. Tatsächlich ist das Dokument ein Foto, schräg aufgenommen, auf einer Laderampe, unter einer Schreibtischlampe, in einem Transporter mit schlechtem Empfang. Der Schritt, der darüber entscheidet, ob der Rest des Workflows funktioniert, steht in fast keiner Anleitung: aus diesem Foto etwas zu machen, das der nächste Node tatsächlich lesen kann.

Genau darum geht es hier, verdrahtet in n8n. Einmal ohne Code, einmal mit einem HTTP-Request-Node.

Was der Workflow braucht, bevor jemand über OCR reden kann

Drei Stufen, und die meisten Tutorials zeigen nur die letzten zwei:

1. Erfassen. Handykamera, Flachbettscanner oder ein Hosted-Link, den Mitarbeiter im Feld einfach öffnen.
2. Normalisieren. Dokument im Bild erkennen, Perspektive korrigieren, Hintergrund bereinigen. Wer das überspringt, vererbt an jeden folgenden Schritt ein schiefes, schattiges Bild: die OCR liest Unsinn, der Klassifizierer rät, und am Ende beschuldigt jemand das Modell.
3. Übergeben. Ein sauberes JPEG oder ein durchsuchbares PDF, dort abgeliefert, wo der Workflow es abholen kann.

n8n ist in Stufe 2 und 3 wirklich gut. In Stufe 1 bleiben Workflows stehen, weil ein Webhook-Node etwas braucht, das dorthin postet, und eine Handykamera das nicht von allein tut.

Weg A: ohne Code, ein Hosted Scanner ruft Ihren Webhook

Das ist der Weg für Mitarbeiter im Feld, Fahrer, Empfang und alle, die nichts installieren sollen.

1. Im ScanKit-Dashboard einen Instant Scanner anlegen. Sie bekommen einen Link und einen QR-Code, und genau eine Einstellung: wohin die fertige Datei geschickt wird.
2. In n8n einen Webhook-Node hinzufügen, Methode POST, und die Production URL kopieren.
3. Diese URL im Scanner als Ziel eintragen. Ab dann schickt jeder Scan das fertige PDF samt Metadaten an den Workflow.
4. Den Workflow ab dem Webhook-Node bauen: die Datei kommt als Binärdaten in $binary.data, die Metadaten als JSON in $json.

Die scannende Person braucht nur einen Browser. Kein Konto, keine App, keine Einweisung über "diesen Link öffnen, Seite fotografieren" hinaus. Das ist der Unterschied zwischen einem Workflow, der benutzt wird, und einem, der einmal vorgeführt wurde.

Weg B: mit Code, der HTTP-Request-Node

Wenn die Bilder schon im Workflow liegen (E-Mail-Anhang, Drive-Datei, Telegram-Foto), brauchen Sie keinen Hosted-Link, sondern einen HTTP-Aufruf, der das Bild bereinigt.

So sieht der Node aus:

• Methode: POST
• URL: https://api.scankit.io/scan/crop
• Authentifizierung: Header Auth, Header-Name Authorization, Wert Bearer IHR_API_KEY. Den Schlüssel als n8n-Credential speichern, nie als einfachen Parameter (siehe die drei Fehler unten).
• Body senden: an, Body Content Type: Form-Data
• Body-Parameter:
  • file vom Typ n8n Binary File, Feldname data (oder wie der vorherige Node es genannt hat)
  • output_width = 1536 (was Sie lesen oder drucken wollen; sinnvoll ist 1024 bis 2048)
  • filter = white für Papier, flat, wenn die Originalfarben bleiben sollen
  • return_pdf = true, wenn Sie ein durchsuchbares PDF statt eines JPEG wollen
  • ocr_lang = eng oder deu, wird nur mit return_pdf verwendet
• Response: Put Output in Field auf data setzen, damit das zurückgegebene PDF wieder als Binärdaten ankommt und der nächste Node es speichern kann.

Mehrseitige Dokumente in einem Aufruf

Wiederholen Sie den Parameter als files für jede Seite und fordern Sie return_pdf=true an. Ein Aufruf, ein Dokument, ein durchsuchbares PDF, statt einer Schleife mit N Anfragen und einem Merge-Node danach. Das ist der Unterschied, ob ein 20-Seiten-Vertrag einen Aufruf kostet oder zwanzig.

Was tatsächlich zurückkommt

Eingabe ist ein JPEG oder PNG. Ausgabe ist ein JPEG oder, mit return_pdf, ein PDF mit OCR-Textebene. PDF ist hier ein Ausgabeformat, kein Eingabeformat: wenn in Ihrem Workflow schon ein PDF liegt, wandeln Sie es zuerst in Seitenbilder um und schicken diese.

Das Bild wird in der EU verarbeitet und nicht gespeichert. Das ist wichtig, wenn personenbezogene Daten drinstehen, und das ist bei den meisten Dokumenten der Fall.

Drei Fehler, die einen Nachmittag kosten

Der Schlüssel im Workflow-JSON. n8n-Workflow-Exporte werden weitergegeben, versioniert und in Foren gepostet. Ein Schlüssel in einem Node-Parameter reist mit. Benutzen Sie immer ein Credential.

Ein umbenanntes Binärfeld. "Put Output in Field: data" schreibt nach $binary.data; erwartet der nächste Node file, bricht er mit einem leeren Body ab, der wie ein API-Fehler aussieht und keiner ist.

Kein Retry bei mobiler Verbindung. Ein Foto-Upload vom Handy mit schlechtem Empfang scheitert einmal und klappt beim zweiten Versuch. Schalten Sie Retry On Fail mit zwei Versuchen und kurzer Wartezeit ein; dann bauen Sie keinen Fallback-Zweig für etwas, das sich selbst heilt.

Was es kostet, ohne Kleingedrucktes

50 Scans sind bei der Anmeldung frei, ohne Karte. Bezahlte Pakete beginnen bei 19 EUR für 1.000 Scans, 49 EUR für 3.000, und Credits verfallen nie. Kein Abo, keine Mindestmenge. Bei diesem Preis ist der Bereinigungsschritt billiger als die Entwicklerstunden, die man mit der Fehlersuche in OCR-Ausgaben verbringt, die auf einem schiefen Foto nie funktionieren konnten.

Wie es weitergeht

Auf der API-Seite gibt es ein Live-Feld, in das Sie ein Dokument legen und das Ergebnis ohne Schlüssel sehen können. Unter Beispiele liegen fertige n8n-Workflows für Rechnungen und Lieferscheine, inklusive der Scanner- und Webhook-Verdrahtung aus diesem Artikel. Und wenn ein bestimmter Node klemmt, schreiben Sie an info@scankit.io: ein Workflow, der fast läuft, ist genau die Art Frage, die sich zu beantworten lohnt.