Ein Tarif für alle Produkte
Ab dem 1. November 2026 hat Ihre Organisation einen Tarif, der Identitätsverifizierung, Authentifizierung sowie Transaktionsüberwachung & Travel Rule abdeckt. Ein gemeinsames Credit-Guthaben deckt die Kosten für alle diese Produkte, und bei Growth und Scale gilt ein Rabatt auf jeden Preis.
- Free: $0 pro Monat zu Listenpreisen. Organisationen, die sich mit einer geschäftlichen E-Mail-Adresse registriert haben, erhalten monatlich $10 Credit für jede Prüfung außer der Telefonverifizierung, die über Aufladungen bezahlt wird
- Growth: $99 pro Monat, $115 Credit pro Monat und 4% Rabatt auf jeden Preis, mit dem Investigator- und Support-Abbruch-Agenten, Fallmanagement mit einer Blaupause und dem Didit-Betrugsnetzwerk
- Scale: $299 pro Monat, $350 Credit pro Monat und 10% Rabatt auf jeden Preis, mit White-Label auf Ihrer eigenen Domain, vollständigem Fallmanagement mit Routing, Netzwerkuntersuchung und priorisiertem Support. Neue Organisationen erhalten eine 14-tägige Scale-Testphase
- Enterprise: ein individueller Jahresvertrag, bei dem Ihre jährliche Verpflichtung als Credit für das Jahr gilt, mit Single Sign-on für Unternehmen und SCIM, organisationsübergreifenden Betrugssignalen und einem benannten Team
- Jährliche Abrechnung: Growth und Scale können einmal im Jahr bezahlt werden, $1,128 bzw. $3,408
- Aufladungen: Bei Free, Growth und Scale wird eine Aufladung zum Nennwert hinzugefügt, die für jedes Produkt verwendet werden kann, und ist 12 Monate gültig. Jede Prüfung verwendet zuerst den Credit des aktuellen Monats und danach Ihre älteste Aufladung
- Enthaltene überwachte Transaktionen: 1,000 pro Monat bei Free, 10,000 bei Growth und 100,000 bei Scale. Jede darüber hinausgehende Transaktion kostet $0.001 zum Listenpreis, bei Growth und Scale abzüglich des Rabatts Ihres Tarifs
- Niedrigere Preise für alle: White-Label sank von $0.20 auf $0.10 pro abgeschlossene Sitzung, die Didit-Gebühr für Codes der Telefonverifizierung von $0.04 auf $0.02 und die E-Mail-Verifizierung von $0.03 auf $0.02 pro Prüfung
- Nachrichten an Ihre Benutzer: E-Mails kosten $0.02 je Nachricht, SMS kosten den Preis des Netzbetreibers pro Segment plus eine Didit-Gebühr von $0.02, und WhatsApp-Nachrichten kosten den WhatsApp-Preis plus eine Didit-Gebühr von $0.02, oder nur die Gebühr, wenn Sie Ihr eigenes WhatsApp-Business-Konto verwenden. Der Rabatt Ihres Tarifs gilt nur für die Didit-Gebühr
- Statusmails bleiben kostenlos: Die Codes, Links und Ergebnisse, die Didit während einer Verifizierung per E-Mail versendet, werden nicht berechnet
- Nichts von Ihrem Einkauf geht verloren: Guthaben, das vor dem 1. November 2026 gekauft wurde, verfällt nie, eine vor diesem Datum verbundene benutzerdefinierte Domain funktioniert weiterhin in jedem Tarif, und unterzeichnete Verträge behalten ihre Bedingungen bis zur Verlängerung
- Abrechnung und Tarif in der Konsole: Sie sehen Ihren Tarif, Credit, Guthaben, die Nutzung pro Prüfung und Belege, ändern den Tarif, laden auf und richten die automatische Aufladung mit einem monatlichen Limit ein
Siehe Preise und Abrechnung und Tarif.
Authentifizierung für Ihre eigenen Benutzer
Die Authentifizierung meldet Ihre Kunden in Ihrer Anwendung an, mit gehosteten Anmeldeseiten unter Ihrem eigenen Origin und einem OAuth-2.0-Ablauf mit PKCE. Nutzen Sie sie allein oder zusammen mit Identitätsverifizierung und Transaktionsüberwachung.
- Alle gängigen Anmeldemethoden: Passwörter, E-Mail-Codes, Magic Links, Telefoncodes, Passkeys, Anmeldung über soziale Netzwerke, Organisations-SSO und Multi-Faktor-Authentifizierung, jeweils pro Anwendung aktivierbar
- Gehostete Seiten: Anmelde-, Magic-Link-, Einladungs- und Seiten zum Zurücksetzen des Passworts unter
https://<slug>.auth.didit.me oder auf Ihrer verifizierten benutzerdefinierten Domain
- Tokens, die Sie prüfen können: ein Access Token, ein ID Token und ein Refresh Token von
POST {origin}/token/, mit Discovery und JWKS unter demselben Origin
- Schutz vor Angriffen: Brute-Force-Sperre, Herausforderungen, Prüfung auf kompromittierte Passwörter, ein Angriffsmodus und Rate-Limits
- Ihre bestehenden Benutzer übernehmen: Konten aus einer JSON- oder CSV-Datei importieren, zuerst einen Testlauf durchführen und prüfen und dann den Import starten
- Zuerst Sandbox: Sandbox-Anwendungen haben einen eigenen Origin und akzeptieren für die lokale Entwicklung
http://localhost-Weiterleitungs-URLs. Live-Anwendungen akzeptieren nur exakt registrierte https://-URLs
- Preise: Die ersten 50,000 aktiven Benutzer jedes Monats sind in jedem Tarif kostenlos, danach ab $0.02 pro aktivem Benutzer. Personen, die sich registrieren und nie wiederkommen, werden nicht berechnet
Didit aktiviert die Authentifizierung pro Anwendung. Bitten Sie uns deshalb, sie zu aktivieren, und testen Sie sie zuerst in einer Sandbox-Anwendung. Die unten genannten Server-SDKs prüfen ihre Tokens. Siehe Authentifizierung, Anmeldemethoden, Bot-Schutz und Migration.
Der Investigator-Agent prüft Ihre Warteschlangen
Der Investigator erstellt für jeden Vorgang, der auf eine Person wartet, einen Bericht: Verifizierungssitzungen und Unternehmensverifizierungen in Prüfung, Treffer bei der laufenden AML-Überwachung, Transaktions-Alerts und Fälle.
- Ein Bericht, den Sie prüfen können: eine Empfehlung (genehmigen, ablehnen, weitere Informationen anfordern oder eskalieren), eine Konfidenzstufe, die Begründung und Belegpunkte, die jeweils auf den Teil des Datensatzes verweisen, aus dem sie stammen
- Screening-Treffer sortiert: Für jeden Screening-Treffer gibt er an, ob es sich um dieselbe Person, nicht um dieselbe Person handelt oder unklar ist
- Zuerst Shadow-Modus: Er schreibt Berichte und vergleicht seine Scores 7, 14 (der Standard) oder 30 Tage lang mit den Entscheidungen Ihres Teams, bevor Sie live gehen. Einrichtung, Shadow-Modus und Backtests werden nie berechnet
- Sie wählen die Autonomie pro Warteschlange: Aus, Vorschlagen (der Standard: eine Person entscheidet über jeden Vorgang), Automatisch (er entscheidet über Vorgänge mit hoher Konfidenz, die Ihre Richtlinie abdeckt) oder Vollautomatisch, mit einem Schwellenwert für die Übereinstimmung, einer Qualitätsstichprobe, einem Tageslimit und einer Betragsobergrenze für Transaktionen
- Feste Leitplanken: Sanktionstreffer gehen immer an eine Person, Gründe im Zusammenhang mit Betrug und AML erreichen nie Endbenutzer, keine Entscheidung nutzt geschützte Merkmale, er reicht niemals einen regulatorischen Bericht ein, und jede Entscheidung wird protokolliert und kann überstimmt werden
- In Ihrem Audit-Log: Die eigenen Entscheidungen des Investigators werden neben denen Ihres Teams erfasst
- Preise: $0.20 pro abgeschlossene Prüfung bei Growth, Scale und Enterprise
Der Investigator läuft niemals auf Sandbox-Anwendungen und wird nach und nach für einzelne Organisationen freigeschaltet. Bitten Sie uns, ihn zu aktivieren. Siehe Investigator-Agent.
Eine neue Business Console und Ask Didit
Die Business Console hat auf allen Seiten ein neues Design, von Startseite und Erste Schritte bis zu Sitzungen, Workflows, Transaktionen, Fällen und Einstellungen. Ask Didit arbeitet darin.
- In einfacher Sprache fragen: Ask Didit findet Sitzungen, beantwortet Fragen zu Ihrer Aktivität und Ihren Genehmigungsquoten und erstellt oder ändert Workflows und Transaktionsregeln
- Sie genehmigen jede Änderung: Wenn Ask Didit Daten schreiben möchte, zeigt es zuerst Diese Aktion bestätigen an. Workflow-Änderungen werden in einer Zusammenfassung mit Rückgängig, Wiederholen, Im Editor öffnen und Entwurf speichern gebündelt
- Dateien anhängen und diktieren: Hängen Sie bis zu vier Dateien mit jeweils höchstens 10 MB an, darunter JPEG-, PNG- oder WebP-Bilder, PDF-, Word-, Klartext-, CSV- und Excel-Dateien, oder nutzen Sie das Mikrofon
Siehe Ask Didit.
Stärkere Betrugssignale
Erkennen Sie Aufnahmen, die eingeschleust statt von der Kamera aufgenommen wurden, und Gesichter aus früheren Angriffen.
- Injection-Angriffe erkannt:
INJECTION_ATTACK_DETECTED markiert eine Dokumentaufnahme oder ein Selfie, das eingeschleust und nicht mit der eigenen Kamera des Geräts aufgenommen wurde, zum Beispiel über eine virtuelle Kamera, einen von der Seite oder durch Browser-Automatisierung erzeugten Kamerastream oder eine manipulierte Kamera. Die Aktion im Schritt Ausweisverifizierung ist standardmäßig Ablehnen. Sie können sie auf Überprüfung oder Keine Aktion setzen
- Gesichter aus früheren Angriffen:
FACE_MATCHES_LIVENESS_ATTACK markiert ein Gesicht, das mit einer früheren Aufnahme eines anderen Benutzers übereinstimmt, die mit hoher Konfidenz als Angriff eingestuft wurde. Setzen Sie es in den Schritten Liveness und Altersschätzung auf Keine Aktion (Standard) oder Überprüfung
- Selfie bei der Dokumentaufnahme in der Gesichtssuche: Das Selfie, das während der Fotografie des Dokuments entsteht, durchläuft dieselbe Gesichtssuche wie das Liveness-Selfie, gegen Ihre Sperrliste für Gesichter und Ihre genehmigten Benutzer. Es hat einen eigenen Schalter im Reiter Regeln des Schritts Ausweisverifizierung. Die Treffer werden in der Sitzung aufgelistet
Siehe Warnungen zur Ausweisverifizierung, Warnungen zur Liveness und Gesichtssuche.
Biometrische Einwilligung
Die Gesetze zum Schutz biometrischer Daten in Illinois (BIPA), Texas (CUBI) und Colorado verlangen einen Hinweis und eine ausdrückliche Einwilligung, bevor ein Unternehmen die Gesichtsgeometrie erfasst. Didit kann den betroffenen Personen vor der ersten Gesichtsaufnahme jetzt einen Einwilligungsschritt anzeigen und deren Antwort in der Sitzung speichern.
- Modus wählen: Automatisch, der Standard, zeigt den Schritt nur an, wenn ein Auslöser zutrifft, etwa der Bundesstaat der Person. Immer fragt in jeder Sitzung, in der ein Gesicht erfasst wird. Nie überlässt die Einholung der Einwilligung Ihnen
- Teilen Sie uns mit, was Sie wissen: Senden Sie
user_state, wenn Sie eine Sitzung erstellen, oder biometric_consent mit der Einwilligung, die Sie bereits eingeholt haben, damit der Ablauf nicht erneut fragt
- Gehosteter Ablauf und natives SDK 4.10.0 oder neuer können den Schritt anzeigen
Didit zeigt den Schritt an und speichert die Antwort. Sie entscheiden, ob Ihr Nutzerablauf den für Ihr Unternehmen geltenden Gesetzen entspricht. Siehe Biometrische Einwilligung.
Fallmanagement
Regulatorische Berichte haben jetzt einen vollständigen Lebenszyklus im Fallmanagement, im Rahmen der Untersuchung zusammen mit den Verifizierungen, Transaktionen und Kundenanfragen.
- Regulatorische Berichte verwalten: Erstellen Sie einen Bericht aus einem Fall oder von der Seite Berichte, verfolgen Sie seinen Lebenszyklus und löschen Sie einen Bericht, den Sie nicht mehr benötigen. Siehe FIU-Berichte
Standortverifizierung
Ein neuer Workflow-Schritt bestätigt, wo sich eine Person während der Verifizierung befindet, und zwar anhand einer einmaligen Geräteposition, die im Browser oder im nativen SDK ausgelesen wird, oder anhand des IP-Standorts der Verbindung.
- Erlaubte und gesperrte Gebiete: Belegen Sie, dass sich die Person innerhalb eines Rechtsgebiets befand, für das Sie lizenziert sind, oder halten Sie sie von Gebieten fern, in denen Sie nicht tätig sind
- Entfernungsprüfungen: Vergleichen Sie die Geräteposition mit dem IP-Standort und mit der Adresse auf dem Dokument der Person
- Spoofing-Signale: Manipulierte Positionen, VPN, Proxy, Tor und Emulatoren erzeugen jeweils eigene Warnungen. Die Aktion jeder Warnung (
NO_ACTION, REVIEW oder DECLINE) legt den Status des Schritts fest, und die stärkste Aktion setzt sich durch
- Eine Messung, mit Einwilligung: Die Person sieht, warum ihr Standort benötigt wird. Der akzeptierte Hinweis wird im Ergebnis gespeichert, und jeder Versuch kann nur einmal abgeschickt werden
- Preise: $0.05 pro Prüfung
Siehe Standortverifizierung.
Adressvalidierung
Prüfen Sie, dass eine Postanschrift existiert, und erhalten Sie sie normalisiert zurück, mit Zustellzeilen, Bestandteilen und Koordinaten.
- Eine neue API:
POST /v3/address-validation/ nimmt die Adresse einzeilig oder als strukturierte Felder entgegen. Das Land ist immer erforderlich. Sie kostet $0.10 pro Adresse
- In Ihren Workflows: Aktivieren Sie die Adressvalidierung in den Schritten Ausweisverifizierung und Adressnachweis und wählen Sie, was geschieht, wenn eine Adresse nicht verifiziert wird
- Nur die Adresse: Ein Ergebnis
verified bedeutet, dass der Ort existiert, nicht dass dort jemand wohnt
Siehe Adressvalidierung.
E-Signatur-Stufen
Mit der E-Signatur können die verifizierte Person oder die gesetzlichen Vertreter und Schlüsselpersonen eines Unternehmens Ihre PDF- und Word-Dokumente innerhalb des Verifizierungsablaufs unterschreiben.
- Einfach, der Standard: Erfordert keine Ausweisverifizierung, keine E-Mail-Adresse und keine Telefonnummer
- Erweitert (AES): Erfordert eine genehmigte Ausweisverifizierung und eine verifizierte E-Mail-Adresse oder Telefonnummer. Der Unterzeichner bestätigt mit einem Einmalcode, der an diesen Kontakt gesendet wird
- Qualifiziert (QES): Wird als Demnächst angezeigt. Das Speichern über die API gibt
400 mit qes_not_available zurück, und QES wird niemals stillschweigend durch Erweitert (AES) ersetzt
- Preise: $0.10 pro signierter Sitzung, Einfach oder Erweitert, unabhängig von der Anzahl der Dokumente. Eine abgelehnte, fehlgeschlagene oder abgelaufene Signatur wird nicht berechnet
See E-Signatur.
Travel Rule
Krypto-Transaktionen erreichen ihre Gegenpartei häufiger, und Sie können jede Nachricht sehen, die noch gesendet werden muss.
- Ermittlung der Gegenpartei: Eine Transaktion, die nur eine Adresse enthält, erreicht ihre Gegenpartei häufiger. Bevor sie als nicht routbar eingestuft wird, versucht Didit der Reihe nach: (1) eine Wallet, deren Kontrolle ein anderer Didit-Kunde nachgewiesen hat, (2) die Zuordnung der Wallet, (3) eine Netzwerkabfrage, sofern ein von Ihnen genutztes Travel-Rule-Netzwerk eine solche anbietet, und (4) die von Ihnen genannte Gegenpartei. Erst dann fragt es den Endbenutzer. Ein VASP, den Sie oder der Endbenutzer ausgewählt haben, hat immer Vorrang
- Zustellung nachverfolgen: Didit sendet jede Nachricht, die eine Transaktion erfordert, und wiederholt den Versuch, bis die Gegenseite sie annimmt. Das Feld
delivery der Transaktion zeigt die neueste Nachricht, ihren Status und ihren Übertragungsweg
- Test ohne Netzwerk-Zugangsdaten: In der Sandbox beantwortet der Didit Test VASP Ihre ausgehenden Transaktionen mit dem Szenario, das Sie wählen, und kann Ihnen eingehende Transaktionen senden, um Ihre Seite zu testen
- Weitere Blockchain-Strukturen: UTXO-Transaktionen sowie Netzwerke, die ein Memo oder ein Tag benötigen
Siehe Travel Rule und Travel Rule in der Sandbox testen.
Wallet-Screening
Wallets in mehr Netzwerken prüfen, mit weniger Angaben, die Sie senden müssen.
- Vier weitere Netzwerke: Das Screening verwalteter Wallets und von Transaktions-Hashes umfasst jetzt Avalanche C-Chain (
AVAX), Cardano (ADA), Stellar (XLM) und Hedera (HBAR), insgesamt 17 Netzwerke
- Weniger Angaben: Lassen Sie das Netzwerk bei einer Bitcoin-, Tron- oder Solana-Adresse weg, und Didit liest es aus dem Adressformat, oder senden Sie einen gängigen Netzwerknamen wie
POLYGON oder BSC. Eine 0x-Adresse benötigt weiterhin ihr Netzwerk: Ohne Angabe antwortet die Anfrage mit 422 (wallet_screening_chain_undetermined) und den infrage kommenden Netzwerken; es wird nichts geprüft und nichts abgerechnet
- Token im richtigen Netzwerk: Ein
0x-Transaktions-Hash für USDT, USDC oder ETH wird in Ethereum, BNB Chain, Polygon, Base, Arbitrum und Optimism gesucht und in dem Netzwerk geprüft, in dem er gefunden wird
Siehe Wallet-Screening.
Unternehmensverifizierung
Bauen Sie Ihre eigenen Onboarding-Masken für Unternehmen über die API und prüfen Sie Steuernummern gegen weitere amtliche Quellen.
- Lite-Prüfung anhand des nationalen Registers in zehn Märkten im asiatisch-pazifischen Raum: In Australien, China, Hongkong, Japan, Neuseeland, Singapur, Südkorea, Taiwan, Thailand und Vietnam durchsucht eine Lite-Prüfung zusätzlich das nationale Unternehmensregister, sodass neu gegründete Unternehmen gefunden werden, sobald das Register sie aufführt. Lite kostet dort $3.00, überall sonst bleibt es bei $2.00. Siehe KYB-Registerpreise
- Headless KYB: Neue Endpoints laden Unternehmensdokumente hoch, geben die daraus extrahierten Parteien zurück, ermöglichen Ihnen, Entwürfe der Parteien zu erstellen, zu aktualisieren und zu löschen, und reichen die Parteien ein. Siehe den Integrationsleitfaden
- Steuernummer- und USt-IdNr.-Prüfung gegen amtliche Quellen: USt-IdNr. und Steuernummern werden gegen amtliche Register geprüft, etwa das USt-Register der EU und die nationalen Steuerregister von Norwegen, der Schweiz, Brasilien, Kolumbien, Costa Rica, Ecuador und Paraguay. In Dutzenden anderen Ländern werden sie anhand des amtlichen Formats und der Prüfziffernregeln geprüft. Eine französische SIREN oder SIRET, eine niederländische RSIN oder eine vollständige ungarische Steuernummer wird vorab in die passende USt-IdNr. umgewandelt. Siehe Unternehmensdaten
Telefonverifizierung
Ihre Marke durchgehend in jedem Verifizierungscode.
- Eigenen SMS-Text und eigene Absender-ID festlegen: Im September war Ihr Name in SMS-Codes enthalten; jetzt können Sie unter White Label → SMS den gesamten Text Ihrer SMS-Codes pro Sprache mit
{code} und {brand} verfassen und Ihre eigene Absender-ID verwenden, wo Mobilfunkanbieter sie zulassen. Wird ein Code über eine Route erneut gesendet, die die Codes nicht übertragen kann, kommt er trotzdem mit dem Text von Didit an, mit Ihrem SMS-Absendernamen signiert, vom Absender von Didit
- WhatsApp-Codes von Ihrer eigenen Nummer: Verbinden Sie Ihre eigene WhatsApp-Business-Nummer, damit Ihre Benutzer Codes von Ihrem Unternehmensnamen und Ihrer Nummer erhalten
Siehe Telefonverifizierung.
Session-API und Webhooks
Sitzungen in jedem Umfang löschen, exportieren und auswerten.
- Tausende Sitzungen in einem Aufruf löschen: Große Löschvorgänge laufen als Job. Wenn mehr als 20 Sitzungen auf eine Anfrage Batch Delete Sessions zutreffen, antwortet die API mit
202 und einem Löschjob. Fragen Sie Get Session Deletion Job ab, bis er COMPLETED oder FAILED meldet. Bis zu 20 Sitzungen werden weiterhin in der Anfrage gelöscht, mit einem Ergebnis pro Sitzung
- Genau die gefilterten Sitzungen löschen: Mit
delete_all: true können Sie einen Löschvorgang mit den Filtern von List Sessions eingrenzen, jeweils mit dem Präfix filter_, zum Beispiel filter_status oder filter_date_from. Ein unbekannter Filter oder ein nicht lesbarer Wert wird abgelehnt, bevor etwas gelöscht wird
- Untergeordnete Verifizierungen mitgezählt: Wird eine Unternehmensverifizierung gelöscht, werden die von ihr erstellten Verifizierungen für Schlüsselpersonen und für das Unternehmen mit gelöscht, und
deleted_child_verifications gibt an, wie viele es sind. Batch Delete Sessions löscht nur KYC-Sitzungen, daher ist der Wert dort immer 0
- In der Warteschlange befindliche Webhooks werden mit einer gelöschten Sitzung verworfen: Webhook-Zustellungen, die für eine gelöschte Sitzung noch in der Warteschlange stehen, und ihre Wiederholungsversuche werden verworfen. Bereits zugestellte Webhooks sind nicht betroffen
- Alle Dateien einer Sitzung in einer ZIP-Datei: Dateien exportieren erstellt eine ZIP-Datei mit den Dokumentseiten, Selfies, Liveness-Videos und hochgeladenen Dokumenten einer KYC- oder KYB-Sitzung in Originalqualität
- Heute stundengenau: Ein neuer Analytics-Endpoint liefert die heutigen Verifizierungen pro lokaler Stunde, die Verifizierungen desselben Wochentags der Vorwoche und die heutigen Ergebnisse
Server-SDKs
Die offiziellen, typisierten Server-SDKs in Version 1.0 für Python, Node.js, Go, Java, PHP, Ruby und .NET rufen die Server-Endpoints auf, prüfen die Webhooks, die Didit Ihnen sendet, und prüfen Authentifizierungs-Tokens. Die API-Referenzseiten zeigen das Code-Beispiel jedes SDK neben der cURL-Anfrage, sobald dessen neueste Version diesen Endpoint abdeckt. Siehe Server-SDKs.
Native-SDKs: zuerst das richtige Land
React Native und Flutter 4.9.1 setzen die iOS- und Android-SDKs auf 4.9.1 fest.
- Zuerst das richtige Land: Wenn die IP-Abfrage erst nach dem Erscheinen des Bildschirms abgeschlossen war, blieben die Länderauswahllisten für Dokumente und den Adressnachweis beim ersten Land der Liste. Jetzt wechseln sie zum erkannten Land, ohne ein in der Sitzung festgelegtes oder vom Benutzer gewähltes Land zu überschreiben
- Android-Korrekturen: Die Header der Fragebögen folgen der Sprache des SDK, und der NFC-Scan von Reisepässen stürzt im vollständigen Paket nicht mehr ab
- Bessere Texte: Die iOS- und Android-SDKs 4.9.1 verbessern die russischen und kirgisischen Verifizierungstexte
Dokumentation und KI-Agenten
Die Dokumentation steht jetzt in mehr Sprachen zur Verfügung, und KI-Agenten können genau den Teil lesen, den sie brauchen.
- Spanisch, brasilianisches Portugiesisch und Japanisch: Ein erstes Paket aus 40 Seiten ist in jede dieser Sprachen übersetzt
- Eine Seite für jeden API-Fehler: API-Fehler listet jeden Status, jede Body-Struktur und jeden stabilen Fehlercode auf, mit Angabe, was sich gefahrlos wiederholen lässt
- Eine Seitenübersicht pro Produkt:
/llms/<product>.md, zum Beispiel /llms/user-verification.md, damit ein KI-Agent die Dokumentation eines einzelnen Produkts statt des vollständigen Index laden kann
- Ein Changelog-Hub unter Alle Updates mit Produktfiltern und einem RSS-Feed
Als Nächstes
Diese Funktionen sind dokumentiert, aber noch nicht in der Produktion aktiviert.
- Japans My Number Card: Der NFC-Schritt liest die My Number Card in den nativen SDKs über JPKI, wobei die Person die PIN der Karte eingibt. Bis dahin überspringt eine My Number Card in einem nativen SDK auf einem NFC-fähigen Smartphone den NFC-Schritt. Siehe NFC-Verifizierung
- Bankverifizierung: Sie bestätigt, dass ein Bankkonto der Person oder dem Unternehmen gehört, die bzw. das in einem früheren Schritt verifiziert wurde, entweder per Anmeldung bei der Bank oder per Kontoprüfung anhand der Daten, die die Person eingibt. Als Ausweichlösungen dienen der Upload eines Kontoauszugs und Micro-Deposits. Continue without your bank steht immer zur Verfügung. Siehe Methoden der Bankverifizierung
Verbesserungen
- Unbekannte Dokumentendesigns markiert: Die Warnung zum Dokumenttyp gilt jetzt auch für eine Dokumentvorderseite, die keinem offiziellen Design entspricht
- Längste Aufbewahrungsdauer als Standard: Eine neue Anwendung startet mit dem längsten Datenaufbewahrungszeitraum ihres Tarifs
Fehlerbehebungen
Ein Fehler erklärt jetzt selbst, was schiefgegangen ist.
- Behoben: Bei den Fehlern von Import Shared Session gibt ein ungültiges, abgelaufenes oder fremdes Share-Token oder ein Token für eine gelöschte Sitzung den Status
400 zurück, mit dem Grund unter share_token
Zuletzt geändert am 7. November 2026