KI-Erkennungs-API auswählen: Zehn Prüfpunkte vor der Integration

Wählen Sie eine KI-Erkennungs-API anhand von zehn Prüfpunkten, die entscheiden, ob sie im Produktivbetrieb trägt: was sie prüft und zurückgibt, welche Eingabelimits gelten, wie Ergebnisse zugestellt werden, ob Webhooks signiert sind, ob Wiederholungen gefahrlos sind, wie sich Fehler und Ratenlimits verhalten, was sie wie lange speichert, ob sich Ergebnisse nachweisen und einer Modellversion zuordnen lassen und was eine fehlgeschlagene Prüfung oder ein Test kostet. Die meisten Punkte lassen sich aus der Dokumentation des Anbieters beantworten, bevor Sie eine Zeile Code schreiben. Der Rest braucht einen kurzen Pilotversuch.

Dieser Ratgeber richtet sich an Entwicklerinnen, Entwickler und technische Einkäufer, die einen Erkennungsdienst an einen Eingangs-, Schaden-, Onboarding- oder Moderationsprozess anbinden. Er prüft die Schnittstelle, nicht den Detektor. Für Genauigkeit, Fehlalarme und Prüfaufwand nutzen Sie den Ratgeber zur Auswahl von Software für KI-Bilder und den Ratgeber zur Zuverlässigkeit. Ein Detektor, der auf Ihren Dateien gut abschneidet, kann im Betrieb trotzdem scheitern, wenn die umgebende API sich schwer wiederholen, nachweisen oder bezahlen lässt.

Zu jedem Punkt steht unten, warum er wichtig ist, wie Sie ihn in der Dokumentation beliebiger Anbieter prüfen und was die Fileverity-API dokumentiert, mit Links zur API-Dokumentation. Dieselben zehn Fragen taugen für jeden Kandidaten; dieser Ratgeber nennt und bewertet keinen Anbieter.

Die zehn Prüfpunkte im Überblick

Die Abbildung zeigt, wo sich jeder Punkt klären lässt. Die Dokumentation sagt, was ein Anbieter verspricht, ein Testschlüssel zeigt die Form von Anfragen und Antworten, und nur ein Pilotversuch mit Ihren eigenen Dateien zeigt Laufzeiten, Löschung und Abrechnung.

Umfang und Eingaben

Modalität und Ausgabe

Warum es wichtig ist. „KI-Erkennung“ umfasst verschiedene Aufgaben: ob ein Bild erzeugt oder bearbeitet wurde, ob ein Dokument verändert wurde oder KI-verfasste Passagen enthält, ob ein reiner Text von einer KI stammt. Ein Anbieter, der eine davon beherrscht, deckt nicht automatisch die anderen ab. Eine Antwort, die nur aus einer Zahl ohne Umfang und Beleg besteht, ist schwer zu verwerten und schwer zu verteidigen. Prüfende müssen wissen, worauf sich ein Befund bezieht, und Ihr Routing-Code braucht ein stabiles, maschinenlesbares Feld.

So prüfen Sie es. Listen Sie die Aufgaben auf, die Sie brauchen, und suchen Sie jede in der Dokumentation unter ihrem Namen. Öffnen Sie das Antwortschema und achten Sie auf vier Dinge: eine maschinenlesbare Zusammenfassung (Urteil, Stufe oder empfohlene Maßnahme), getrennt von den Einzelbefunden; Belege, die ein Mensch lesen kann; einen Zustand „nicht beurteilbar“, der sich von „negativ“ unterscheidet; und eine Schemaversion. Bitten Sie um Beispielantworten für einen Treffer, ein unauffälliges Ergebnis, ein nicht eindeutiges Ergebnis und einen Fehler. Wie Sie die Antworten festhalten, zeigt die Abdeckungsmatrix im Auswahl-Ratgeber.

Was Fileverity dokumentiert. Drei Modelle, jeweils mit Limits und Snapshot über GET /models aufgelistet: fvimg-2 für Bilder, fvdoc-3 für Dokumente und fvdoc-3-text für reinen Text. Bild- und Dokumentprüfungen liefern einen vollständigen Bericht mit Zusammenfassungsstufe und empfohlener Maßnahme, den Einzelbefunden, einer Berichts-ID und einem versiegelten PDF. Textprüfungen liefern ein Ergebnis mit Urteil (KI-verfasst, gemischt oder von Menschen verfasst), Werten und den markierten Passagen. Die Dokumentation hält fest, dass ein Textergebnis eine statistische Schätzung und kein Urheberschaftsnachweis ist und allein keine Entscheidung tragen sollte, die eine Person betrifft. Siehe Übersicht, Das Berichtsobjekt und Textprüfungen oder die Seiten KI-generierte Bilder per API erkennen und Dokumentenfälschung per API erkennen.

Eingabelimits

Warum es wichtig ist. Limits entscheiden, ob Ihr tatsächlicher Eingang passt: Handyfotos, Screenshots, Scans, mehrseitige PDFs, passwortgeschützte Dateien, lange Texte. Ein Limit, das Sie erstmals im Betrieb treffen, zeigt sich als fehlgeschlagene Anfragen und verärgerte Nutzende.

So prüfen Sie es. Suchen Sie die Limits je Modalität: akzeptierte Formate, maximale Größe, Pixel oder Seiten, Textlänge und Sprachen. Prüfen Sie, wie große Dateien hochgeladen werden (eine Anfrage oder ein vorsigniertes Hochladen), ob das Format am Inhalt erkannt oder dem Dateinamen geglaubt wird und was jede Überschreitung zurückgibt. Ein eigener Fehlercode ist ein gutes Zeichen; stilles Abschneiden oder ein pauschaler 400 nicht. Reichen Sie dann die größten, kleinsten und sperrigsten Dateien ein, die bei Ihnen tatsächlich eingehen, etwa Unterlagen aus einer Schadenmeldung oder einem Kreditantrag.

Was Fileverity dokumentiert. Dateien listet die unterstützten Formate und Limits je Modell, einen direkten Multipart-Upload und einen vorsignierten Upload für größere Dateien, die Formaterkennung am Dateiinhalt und einen Fehlercode je Limit. Verschlüsselte Dokumente nehmen eine Passwortoption an (Analysen). Textlänge und Sprachen stehen in Textprüfungen.

Ergebnisse und Zustellung

Warten auf Ergebnisse

Warum es wichtig ist. Ein Aufruf, der im Labor Sekunden dauert, kann unter Last länger brauchen, und Ihre eigene Plattform hat Zeitlimits: Serverless-Funktionen, Gateways, Anfragen von Nutzenden. Anbieter antworten auf zwei Arten. Ein synchroner Aufruf liefert das Ergebnis in der Antwort. Ein asynchroner Aufruf antwortet sofort mit einem Status, und Sie holen das Ergebnis später ab. Eine Integration, die für den ersten Fall geschrieben wurde und auf den zweiten trifft, verliert Ergebnisse oder blockiert Nutzende. Die Abbildung zeigt die drei Wege, auf denen ein asynchrones Ergebnis bei Ihrem Code ankommt.

So prüfen Sie es. Suchen Sie den Statuslebenszyklus (processing, succeeded, failed, canceled) und, falls der Anbieter eine Anfrage offen halten kann, die dokumentierte maximale Wartezeit. Prüfen Sie, wie und in welchem Takt abgefragt wird, was bei ausgelasteter Kapazität geschieht, ob wartende Aufträge ihre Position melden und ob sich ein Auftrag kostenfrei abbrechen lässt. Ein 503 mit Retry-After-Header, definiert in RFC 9110, sagt Ihrem Code, was zu tun ist. Messen Sie im Pilot die Gesamtdauer bei erwartetem Volumen für Ihren langsamsten Dateityp. Ein Testmodus, der sofort antwortet, sagt dazu nichts.

Was Fileverity dokumentiert. Eine Textprüfung ist synchron: Das Ergebnis steht in der Antwort. Bild- und Dokumentprüfungen sind asynchron: Das Anlegen liefert 202 mit status: processing. Sie können die Anfrage mit einem Prefer: wait-Header offen halten, GET /analyses/{id} abfragen oder einen Webhook abonnieren, und Sie sollten 202 auch beim Warten behandeln, weil Dokumente in eine Warteschlange kommen können. Bei ausgelasteter Kapazität liefert das Anlegen 503 service_unavailable mit retry-after und wird nicht berechnet. Eine noch laufende Dokumentprüfung lässt sich kostenfrei abbrechen. Siehe Warten, Polling oder Webhooks und Wenn der Dienst ausgelastet ist.

Webhook-Signatur

Warum es wichtig ist. Ein Webhook-Endpunkt ist eine öffentliche URL, die Anfragen annimmt, welche Ihre Falldaten ändern. Ohne Prüfung kann jeder, der sie findet, ein gefälschtes „unauffälliges“ Ergebnis senden. Die Zustellung ist zudem von Natur aus unzuverlässig: Ihr Server startet neu, der Absender muss also wiederholen, was Duplikate und vertauschte Reihenfolgen erzeugt.

So prüfen Sie es. Suchen Sie ein dokumentiertes Signaturverfahren: ein Geheimnis je Endpunkt, eine Signatur über den rohen Request-Body und einen Zeitstempel, damit sich alte Anfragen verwerfen lassen. Die Standard-Webhooks-Spezifikation ist eine offene Konvention mit den Headern webhook-id, webhook-timestamp und webhook-signature und einer HMAC-SHA256-Signatur, sodass vorhandene Bibliotheken sie prüfen können. Achten Sie außerdem darauf, wie Geheimnisse erneuert werden, wie der Wiederholungsplan aussieht und wann er endet, ob es eine stabile Ereignis-ID zur Deduplizierung gibt, ob die Nutzlast das Ergebnis oder nur eine ID enthält, wie Ihnen Ausfälle gemeldet werden (Zustellprotokoll, erneutes Senden, deaktivierte Endpunkte) und ob Sie ein Testereignis auslösen können. Lassen Sie im Pilot Ihren Endpunkt einmal einen Fehler zurückgeben und senden Sie dann einen manipulierten Body und einen veralteten Zeitstempel.

Was Fileverity dokumentiert. Webhooks folgen Standard Webhooks, mit den drei Headern und einer HMAC-SHA256-Signatur über Ereignis-ID, Zeitstempel und rohen Body. Das Signaturgeheimnis wird einmal angezeigt und lässt sich erneuern; die Dokumentation enthält Prüfcode in JavaScript und Python. Die Zustellung erfolgt mindestens einmal ohne Reihenfolgegarantie, deduplizieren Sie also über webhook-id. Fehlgeschlagene Zustellungen werden mit wachsenden Abständen über mehrere Tage wiederholt, ein dauerhaft fehlschlagender Endpunkt wird deaktiviert und die Inhaber des Workspace erhalten eine E-Mail; die Konsole listet die letzten Zustellungen und kann eine erneut senden. Send test liefert ein signiertes Beispielereignis. Das Ereignis enthält nicht das Ergebnis: Rufen Sie es mit GET /analyses/{id} ab. Textprüfungen sind synchron und senden keine Webhooks, und Testschlüssel senden nie Ereignisse. Siehe Signatur prüfen und Zustellung und Wiederholungen.

Verlässlichkeit bei Wiederholungen und Last

Idempotenz und Wiederholungen

Warum es wichtig ist. Netzwerke fallen zwischen Ihrer Anfrage und der Antwort aus. Kann eine Wiederholung eine zweite Prüfung anlegen, zahlen Sie doppelt und eröffnen womöglich einen doppelten Fall. Wiederholen Sie nie, verlieren Sie Arbeit. Ein Idempotenzschlüssel lässt den Anbieter eine Wiederholung erkennen und das erste Ergebnis zurückgeben.

So prüfen Sie es. Suchen Sie einen Idempotenz-Header an jedem Endpunkt, der etwas anlegt oder Geld kostet. Lesen Sie, was geschieht, wenn derselbe Schlüssel erneut gesendet wird (dieselbe Antwort, als Wiederholung gekennzeichnet), wenn er mit anderem Body wiederverwendet wird (er sollte abgelehnt statt stillschweigend akzeptiert werden), solange die erste Anfrage noch läuft und nach einem Fehler, dazu wie lange Schlüssel gespeichert werden und worauf sie sich beziehen. Der Header wird in einem IETF-Entwurf beschrieben, der im November 2026 noch kein RFC war; Anbieter unterscheiden sich im Detail, testen Sie also. Senden Sie im Pilot dieselbe Anfrage zweimal und brechen Sie die Verbindung mitten in der Anfrage ab; bestätigen Sie dann ein Ergebnis und eine Abrechnung.

Was Fileverity dokumentiert. Ein Idempotency-Key-Header funktioniert an jedem POST-Endpunkt: Textprüfungen, Datei-Uploads, Anlegen und Abbrechen von Prüfungen. Eine Wiederholung liefert die gespeicherte Antwort mit idempotent-replayed: true, und nichts läuft oder wird erneut berechnet. Derselbe Schlüssel mit anderem Body liefert 409 idempotency_mismatch, derselbe Schlüssel bei noch laufender erster Anfrage 409 idempotency_in_progress. Fehlerantworten werden nicht gespeichert, eine Wiederholung nach einem Fehler führt die Anfrage also erneut aus. Schlüssel gelten je Workspace, Modus (live oder test) und Endpunkt und werden für einen dokumentierten Zeitraum aufbewahrt. Siehe Idempotenz.

Fehler und Request-IDs

Warum es wichtig ist. Ihr Code muss entscheiden, was er wiederholt, was er korrigiert, was er Nutzenden anzeigt und was er an den Support des Anbieters weitergibt. Fehlermeldungen als Fließtext ändern sich mit der Zeit, und Code, der sie auswertet, bricht. Eine Request-ID lässt beide Seiten dieselbe Anfrage später wiederfinden.

So prüfen Sie es. Suchen Sie Fehler in einer einheitlichen JSON-Form mit einem stabilen, maschinenlesbaren Code, getrennt von der Meldung für Menschen, eine Tabelle aller Codes mit HTTP-Status und der Angabe, ob wiederholt werden soll, und eine Request-ID in einem Antwort-Header jeder Antwort, auch bei Erfolg. Prüfen Sie, ob die Dokumentation sagt, ob eine fehlgeschlagene Prüfung berechnet wird. Lösen Sie im Pilot jede Fehlerklasse aus (ungültiger Schlüssel, zu große Datei, nicht unterstütztes Format, unbekannte ID, leeres Guthaben) und bestätigen Sie, dass sich allein am Code erkennen lässt, welche es ist.

Was Fileverity dokumentiert. Fehler tragen type, code, message, param und request_id, und die Dokumentation rät, nach code statt nach der Meldung zu verzweigen. Jede Antwort hat einen x-request-id-Header, und die Tabelle der Fehlercodes wird aus den eigenen Definitionen der API erzeugt. Die Dokumentation nennt, welche Fehler Sie wiederholen und welche Sie zuerst beheben sollten, und eine Prüfung, die mit einem Fehler endet, wird nicht berechnet. Nennen Sie die Request-ID, wenn Sie an hello@fileverity.com schreiben oder die Kontaktseite nutzen. Siehe Fehler.

Ratenlimits

Warum es wichtig ist. Ein Schub, etwa der Import eines Rückstaus oder ein Monatsabschluss, kann Limits auslösen. Ungesteuert führt er zu Fehlern und Wiederholungen, die alles verschlimmern. Limits zeigen auch, wie der Anbieter genutzt werden soll: Last verteilen und Webhooks dem engen Abfragen vorziehen.

So prüfen Sie es. Suchen Sie das Limit je Schlüssel oder Konto samt Zeitfenster, Antwort-Header mit Limit, Rest und Zeitpunkt des Zurücksetzens sowie eine 429-Antwort mit Retry-After-Header (RFC 6585 definiert den Status 429). Achten Sie auf weitere Obergrenzen, etwa für gleichzeitige oder ausstehende Uploads, und darauf, wie sich höhere Limits beantragen lassen. Wendet der Testmodus des Anbieters dieselben Limits an, probieren Sie dort zuerst einen Schub aus.

Was Fileverity dokumentiert. Jeder API-Schlüssel hat ein Limit pro Minute, das alle Endpunkte umfasst, auch Anfragen, die einen Fehler liefern. Jede authentifizierte Antwort trägt x-ratelimit-limit-requests, x-ratelimit-remaining-requests und x-ratelimit-reset-requests, und 429 rate_limited trägt retry-after. Eine eigene Obergrenze für nicht abgelaufene hochgeladene Dateien liefert pending_files_limit, ohne retry-after. Test- und Live-Schlüssel teilen sich die Ratenlimits, Sie können das Zurückfahren also mit einem Testschlüssel üben. Höhere Limits vereinbaren Sie über den Vertrieb. Siehe Rate-Limits und Header.

Daten, Nachweise und Kosten

Datenspeicherung

Warum es wichtig ist. Zur Prüfung eingereichte Dateien sind oft personenbezogen oder vertraulich: Schadenfotos, Gehaltsabrechnungen, Verträge. Der Anbieter wird zum Auftragsverarbeiter dieser Daten. Sie müssen wissen, was gespeichert wird, wo, wie lange, wer Zugriff hat und ob die Daten zum Training von Modellen dienen.

So prüfen Sie es. Fordern Sie eine Antwort je Datenkategorie: hochgeladene Dateien, übermittelter Text, abgeleitete Daten, Ergebnisse, Protokolle und Backups. „Wir löschen Dateien“ ist keine Antwort, solange nicht feststeht, was gelöscht wird, wann und was bleibt. Suchen Sie eine Aufbewahrungstabelle in der Dokumentation, eine Möglichkeit zur früheren Löschung, die Verarbeitungsorte und Unterauftragsverarbeiter, eine Aussage zur Trainingsnutzung, einen Vertrag zur Auftragsverarbeitung und eine Option für private Bereitstellung. Enthalten die Dateien personenbezogene Daten, dürfen Sie nach Art. 28 DSGVO nur Auftragsverarbeiter mit hinreichenden Garantien einsetzen und schließen dazu einen Vertrag zur Auftragsverarbeitung (AVV) ab (Datenschutzkonferenz, Kurzpapier Nr. 13). Für Verarbeitung außerhalb der EU gelten zusätzlich Art. 44 ff. DSGVO; die Liste der Angemessenheitsbeschlüsse der EU-Kommission nennt die anerkannten Länder, und jeden Verarbeitungsort prüfen Sie gesondert. Die rechtliche Einordnung nehmen Ihre Datenschutzbeauftragten vor. Bestätigen Sie im Pilot, dass eine Datei nach ihrer Prüfung gelöscht ist und gespeicherte Ergebnisse wie dokumentiert ablaufen.

Was Fileverity dokumentiert. Eine Aufbewahrungstabelle in Datenaufbewahrung und Sicherheit deckt jede Datenkategorie ab. Hochgeladene Dateien werden gelöscht, sobald eine Prüfung startet, und in jedem Fall nach einer angegebenen Frist; DELETE /files/{id} entfernt eine früher. Übermittelter Text wird ausgewertet und verworfen, nie gespeichert. Prüfergebnisse werden für einen begrenzten Zeitraum aufbewahrt, Textergebnisse ohne den Text. Belege zu Dokumenten (Seitenbilder, Textauszüge) werden kürzer aufbewahrt als das Ergebnis; laden Sie den PDF-Bericht nach Abschluss der Prüfung herunter, wenn er diese Belege enthalten soll. Anfrageprotokolle enthalten weder Anfrage- noch Antwort-Bodys. Verarbeitungsorte und Unterauftragsverarbeiter stehen auf der Seite Sicherheit, die Bedingungen im Vertrag zur Auftragsverarbeitung, und eine private Bereitstellung wird Enterprise-Kunden auf Anfrage angeboten.

Nachweise und Modellversionen

Warum es wichtig ist. Wird ein gemeldeter Fall Monate später angefochten, müssen Sie zeigen, was wann mit welcher Version welches Modells geprüft wurde und dass sich die Datei seither nicht geändert hat. Ein nackter Wert in Ihrer Datenbank leistet das nicht. Ändert ein Anbieter sein Modell ohne Ankündigung, können sich Ergebnisse auf derselben Datei ändern; dann lassen sich Pilotergebnis und Produktion nicht vergleichen und der Unterschied zwischen zwei Prüfungen nicht erklären.

So prüfen Sie es. Suchen Sie eine stabile ID je Ergebnis, die Sie beim Fall speichern, einen Fingerabdruck (Hash) der geprüften Datei, einen vertrauenswürdigen Zeitstempel einer Zeitstempelstelle (RFC 3161), damit die Zeit nicht allein auf der Uhr des Anbieters beruht, einen herunterladbaren Bericht und eine Möglichkeit für Dritte, ihn ohne Konto zu bestätigen. Prüfen Sie, ob jedes Ergebnis die genaue Modellversion nennt, ob Sie eine Anfrage auf eine Version festlegen können und wie lange diese verfügbar bleibt und wie Änderungen und Abkündigungen mitgeteilt werden. Der Ratgeber zu Zeitstempel und SHA-256-Prüfsumme erklärt, was Hash und Zeitstempel jeweils belegen.

Was Fileverity dokumentiert. Bild- und Dokumentberichte tragen eine Berichts-ID, den SHA-256-Fingerabdruck der geprüften Datei, einen RFC-3161-Zeitstempel und eine öffentliche Verifizierungsseite, die jeder mit dem Link ohne Konto nutzen kann, dazu ein versiegeltes PDF. Jedes Ergebnis nennt den Snapshot, der es erzeugt hat, eine Modell-ID wie fvimg-2 verweist auf einen datierten Snapshot, und wer eine Snapshot-ID als model übergibt, legt die Anfrage darauf fest. Änderungen an v1 sind additiv und im Changelog verzeichnet; Clients sollten daher unbekannte Felder ignorieren. Textergebnisse tragen eine Erkennungs-ID und den Snapshot, der sie erzeugt hat. Kündigungsfristen für das Abschalten eines Snapshots gehören in Ihren Vertrag, fragen Sie danach schriftlich. Siehe Das Berichtsobjekt, Konventionen und das Änderungsprotokoll.

Abrechnung und Testmodus

Warum es wichtig ist. Eine Preisliste verbirgt die Regeln, die die Rechnung bestimmen: die abrechenbare Einheit, den Umgang mit fehlgeschlagenen, abgebrochenen oder wiederholten Prüfungen, die Rundung und die Kosten eines durchgehenden Jobs. Außerdem müssen Sie die Integration bauen und testen können, ohne Geld auszugeben oder Produktionsdaten zu verunreinigen.

So prüfen Sie es. Suchen Sie die Abrechnungseinheit je Modalität (je Bild, je Dokument, je Zeichenblock) und die Rundungsregel. Prüfen Sie, ob fehlgeschlagene, abgebrochene und abgelehnte Anfragen berechnet werden, ob das Modell vorausbezahlt oder ein Abonnement ist und ob es Ausgabenlimits, Warnungen bei niedrigem Guthaben und einen Nutzungsbericht gibt, den Sie mit Ihren eigenen Zahlen abgleichen können. Ein guter Testmodus berechnet nie, wendet dieselbe Validierung an und sagt genau, was er simuliert und was nicht: Laufzeiten, Webhooks und echte Ergebnisse sind die üblichen Lücken. Gleichen Sie im Pilot den Nutzungsbericht des Anbieters mit Ihrem eigenen Protokoll ab, einschließlich eines absichtlichen Fehlschlags.

Was Fileverity dokumentiert. Die API ist vorausbezahlt aus dem Guthaben des Workspace, ohne Abonnement. Preise gelten je Bildprüfung, je Dokumentprüfung und je Zeichenblock Text, pro Anfrage aufgerundet. Bei Bild- und Dokumentprüfungen wird der Preis beim Anlegen reserviert und bei Fehlschlag oder Abbruch freigegeben; vor der Auswertung abgelehnte Anfragen werden nicht berechnet. Der kostenlose Start wird vor dem Guthaben verbraucht. Jeder Schlüssel kann ein monatliches Ausgabenlimit haben, eine Warnung bei niedrigem Guthaben sendet eine E-Mail und einen balance.low-Webhook, und jede Prüfung meldet ihre Kosten in usage. Testschlüssel berechnen nie und nutzen den kostenlosen Start nicht, liefern sofort ein festes Beispiel, wenden dieselbe Validierung, dieselben Ratenlimits und dieselben Fehlercodes an und senden keine Webhooks außer dem Testereignis der Konsole. Beispiel-Berichts-IDs beginnen mit FV-TEST- und haben keine öffentliche Verifizierungsseite. Aktuelle Preise stehen in Preise und Abrechnung und auf der API-Seite; das Verhalten der Testschlüssel steht in Authentifizierung und Schlüssel.

Häufige Fragen

Soll ich eine synchrone oder eine asynchrone API wählen?

Keine ist an sich besser. Kurze Eingaben wie reiner Text passen zu einem synchronen Aufruf, und Dateien mit aufwendigerer Analyse liefern meist zuerst einen Status. Entscheidend ist, dass die Dokumentation den Lebenszyklus definiert, Warten, Abfragen und Webhooks unterstützt und Ihr Code einen ausstehenden Status behandelt.

Brauche ich Webhooks, oder reicht Polling?

Für einen Prototyp oder ein geringes Volumen reicht Polling. Webhooks sparen Anfragen und Ratenlimit-Budget und passen zum Produktivbetrieb. In beiden Fällen prüfen Sie die Signatur und behandeln Duplikate und einen ausstehenden Zustand.

Ist ein Idempotenzschlüssel genormt?

Er ist eine verbreitete Konvention, die ein IETF-Entwurf beschreibt, der im November 2026 noch kein RFC geworden war. Behandeln Sie das genaue Verhalten als anbieterspezifisch und testen Sie es. Das von Fileverity steht auf der Seite Idempotenz.

Heißt eine gute API, dass der Detektor zuverlässig ist?

Nein. Diese Prüfpunkte betreffen die Integration, nicht die Erkennungsqualität. Bewerten Sie die Erkennung an Ihren eigenen Dateien, mit Labels, denen Sie vertrauen, anhand des Ratgebers zur Zuverlässigkeit und des Auswahl-Ratgebers.

Kann ich die Fileverity-API ausprobieren, ohne zu zahlen?

Ja. Ihr erster Workspace enthält einen kostenlosen Start, und Testschlüssel berechnen nie. Folgen Sie dem Schnellstart und lesen Sie Preise und Abrechnung für die Bedingungen.

Eine Checkliste für den Pilot

Führen Sie den Pilot in drei Durchgängen und halten Sie jede Antwort datiert fest. Zuerst ein Schreibtischdurchgang: Beantworten Sie alle zehn Prüfpunkte aus der Dokumentation jedes Kandidaten und scheiden Sie klar ungeeignete Kandidaten aus, bevor Sie Code schreiben. Dann ein Durchgang mit Testschlüssel: Bauen Sie die Integration gegen den Testmodus. Schließlich ein Live-Durchgang: Nutzen Sie einen Live-Schlüssel mit niedrigem Ausgabenlimit und eine Stichprobe von Dateien, die Sie senden dürfen. Für Stichprobe, Labels und Bewertung der Erkennungsqualität selbst folgen Sie dem Pilotdesign in Software zur Erkennung von KI-Bildern auswählen.

Halten Sie die Antworten neben der Abdeckungsmatrix und der Bewertung aus dem Auswahl-Ratgeber bereit. Für den Einstieg mit Fileverity lesen Sie die API-Seite, die Seiten zu Bildern und Dokumenten und den Schnellstart.

Von Yang Zheng · Geprüft von Bill Liu