> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Daten von einem anderen Anbieter importieren > Wählen Sie den passenden Didit-Importweg für Sitzungen, Benutzer, Gesichter, Sperrlisten, Unternehmen, Transaktionen und Workflow-Status-Regeln. Dieser Leitfaden hilft Ihnen, den richtigen Importpfad zu wählen, wenn Sie Daten von einem anderen Anbieter in Didit übernehmen. Unter „Import“ werden häufig zwei verschiedene Vorgänge verstanden:- **Historische Verifizierungsvorgänge importieren**: Abgeschlossene KYC-, KYB-, Transaktionsüberwachungs- oder Workflow-Regeldatensätze werden neu angelegt, damit Didit die bisherige Anbieterhistorie anzeigt. Verwenden Sie `POST /v3/session/imports/`. - **Betriebsdaten importieren**: Benutzer, Unternehmen, Profilgesichter, Einträge auf der Sperrliste oder auf der Zulassungsliste werden angelegt, damit Didit sie bei künftigen Prüfungen nutzen kann. Verwenden Sie die APIs für Entitäten, Gesichter und Listen.Verifizierungsimporte erstellen historische Datensätze mit `session_type: "MIGRATED"` für KYC und KYB. Sie senden keine E-Mails an Endbenutzer, leiten Benutzer nicht in den gehosteten Ablauf weiter und führen die ursprüngliche Verifizierung nicht erneut aus. Die importierten Datensätze erscheinen, sofern zutreffend, in Sitzungslisten, in Entitätsprofilen, in Transaktionsansichten und unter `GET /v3/session/{session_id}/decision/`.## Welchen Import sollten Sie verwenden?| Ziel | Dieser Importpfad | Was dabei erstellt wird | Am besten geeignet für | | - | - | - | - | | Historische KYC-Sitzungen neu anlegen | `POST /v3/session/imports/` mit `import_type=user_verification` | `Session`, Ausweisverifizierungsdaten, optionale Dokument- und Selfie-Bilder, Dokument- und Liveness-Videos, Tags, Metadaten | Übernahme abgeschlossener Antragsteller von Sumsub, MetaMap, Veriff, Onfido, Persona, Jumio, Incode, iDenfy, Trulioo oder einem anderen KYC-Anbieter | | Historische KYB-Sitzungen neu anlegen | `POST /v3/session/imports/` mit `import_type=business_verification` | `BusinessSession`, Unternehmensdaten aus Registern, leitende Funktionsträger, wirtschaftlich Berechtigte, Tags, Metadaten | Übernahme abgeschlossener Unternehmensprüfungen von KYB-Anbietern, Anbietern von Unternehmensregistern oder internen KYB-Tools | | Historische Datensätze der Transaktionsüberwachung neu anlegen | `POST /v3/session/imports/` mit `import_type=transactions` | `Transaction`, Parteien (betroffene Partei und Gegenpartei), Ergebnisse des Anbieters, Travel Rule-Daten, Netzwerk-Snapshot, Metadaten | Übernahme der Historie aus Regel-Engines, KYT, Wallet-Screening oder Fiat-Transaktionsüberwachung | | Benutzerdefinierte Workflow-Statusregeln importieren | `POST /v3/session/imports/` mit `import_type=status_rules` | `VerificationSettings.feature_status_rules` | Übernahme von Richtlinienlogik aus einem anderen Anbieter oder einer Tabellenkalkulation in die Workflow-Engine von Didit | | Benutzer ohne historische Sitzungen anlegen | `POST /v3/users/create/` oder CSV-Import in der Console | `VendorUser`-Profilzeilen | Laden Ihrer Benutzerliste, bevor neue Didit-Prüfungen gestartet werden | | Vertrauenswürdige Profilgesichter Benutzern zuordnen | `POST /v3/organization/{organization_id}/application/{application_id}/vendor-users/by-id/{didit_internal_id}/faces/upload/` | Profilgesichts-Nachweise, indiziert für die Erkennung von Duplikaten und die Gesichtssuche | Migration von Profilgesichtsbildern von einem anderen KYC-Anbieter, ohne vollständige Sitzungen neu anzulegen | | Gesichter auf Sperr- oder Zulassungsliste setzen | `POST /v3/lists/{list_uuid}/entries/face-upload/` oder `POST /v3/lists/{list_uuid}/entries/` mit `reference_session_id` | Listeneintrag für Gesichter und biometrisches Embedding | Migration bekannter Betrugsgesichter und vertrauenswürdiger Gesichter auf der Zulassungsliste oder Sperren eines Gesichts aus einer bestehenden Didit-Sitzung | | Unternehmen ohne historische KYB-Sitzungen anlegen | `POST /v3/businesses/create/` oder CSV-Import in der Console | `VendorBusiness`-Profilzeilen | Laden Ihrer Unternehmenskundenliste, bevor KYB-Prüfungen durchgeführt werden |> [!NOTE] > > Wenn Sie für künftige Prüfungen nur ein Benutzer- oder Unternehmensprofil benötigen, importieren Sie keine historische Verifizierungssitzung. Verwenden Sie stattdessen die APIs für die Entitäten Benutzer und Unternehmen. Wenn die Entscheidung, die Dokumentfelder, Warnungen oder Nachweise des bisherigen Anbieters in Didit als Compliance-Historie erscheinen sollen, verwenden Sie `POST /v3/session/imports/`.## Welche Daten lassen sich von welchem Anbieter migrierenDidit akzeptiert eine kanonische CSV- oder NDJSON-Datei. Sie können also von jedem Anbieter migrieren, sobald Sie die Daten exportiert und umgewandelt haben. Das Importformat ist immer das kanonische Schema von Didit.| Anbieterfamilie | Typische Quellen | In der Regel migrierbar | Hinweise | | - | - | - | - | | KYC-Anbieter | Sumsub, MetaMap, Veriff, Onfido, Persona, Jumio, Incode, iDenfy, Trulioo, HyperVerge, AU10TIX, Mitek, Ondato | Antragsteller-ID, Anbieter-Benutzer-ID, Entscheidungsstatus, Dokumentfelder, Dokumentbilder, Selfie-/Liveness-Bild, Ablehnungskennzeichnungen, Tags, rohe Anbieter-Metadaten | Verwenden Sie `import_type=user_verification`. Wenn der Anbieter keine Bilder exportieren kann, importieren Sie die strukturierten Felder und lassen Sie die Bild-URLs leer. | | KYB-Anbieter | Anbieter von Unternehmensregistern, Sumsub KYB, Trulioo KYB, Registerexporte im Stil von Creditsafe, interne KYB-Tools | Unternehmensname, Registernummer, Land, Registerstatus, Organmitglieder, wirtschaftlich Berechtigte, Risikostufe, roher Register-Payload | Verwenden Sie `import_type=business_verification`. Organmitglieder und UBOs werden als JSON-Arrays übergeben. | | Transaktionsüberwachung / KYT-Anbieter | Sumsub Transaction Monitoring, KYT-Exporte im Stil von Chainalysis, Crystal, Merkle Science, Sardine, Unit21, Alloy, interne Regel-Engines | Transaktions-ID, Betrag, Währung, Richtung, Subjekt/Gegenpartei, Regeltreffer, Anbieterergebnisse, Travel-Rule-Status, Snapshot des Netzwerkgraphen | Verwenden Sie `import_type=transactions`. Importierte Transaktionen sind historische Datensätze; sie werden standardmäßig nicht erneut geprüft. | | Workflow- und Richtlinientabellen | Exporte von Compliance-Richtlinien, Regeltabellen der Anbieter, interne Risiko-Tabellen | Statusregeln pro Funktion, etwa „wenn das Ausstellungsland X ist, Ausweisverifizierung auf In Prüfung setzen“ | Verwenden Sie `import_type=status_rules`. Regeln werden vor dem Speichern gegen den Feldkatalog der Workflows von Didit validiert. | | Benutzer- und Profilspeicher | CRM, Kundendatenbank, Benutzerexport des Anbieters, Data Warehouse | `vendor_data`, Anzeigename, Metadaten, Tags, vertrauenswürdige Gesichtsbilder | Verwenden Sie die Benutzer-APIs und den Upload von Profil-Gesichtsbildern. Das ist nicht dasselbe wie eine abgeschlossene Verifizierungssitzung. | | Sperrlisten- und Allowlist-Daten | Betrugslisten der Anbieter, interne Betrugs-Ops-Tabellen, Chargeback-Listen, interne Listen im Sanktionsumfeld | E-Mail-Adressen, Telefonnummern, Dokumente, Wallets, IP-Adressen, Geräte-Fingerprints, Gesichter, Länder, Benutzer, Unternehmen | Verwenden Sie die Listen-APIs. Für Gesichtsbilder verwenden Sie den dafür vorgesehenen Gesichts-Upload-Endpoint, damit Didit das Gesichts-Embedding extrahieren kann. |## Migrationsablauf1) Entscheiden Sie, ob Sie Verlauf, Profile, Gesichter, Listen, Transaktionen oder Regeln importieren möchten. 2) Exportieren Sie die Daten selbst aus dem alten Anbieter. Senden Sie keine API-Schlüssel des alten Anbieters an Didit. 3) Wandeln Sie den Export des Anbieters in die passende kanonische CSV- oder NDJSON-Vorlage von Didit um. 4) Bei großen Migrationen sollten Sie NDJSON bevorzugen und die Daten in Dateien aufteilen, die sich unabhängig voneinander erneut verarbeiten lassen. 5) Erstellen Sie den Importauftrag und fragen Sie den Fortschritt ab. 6) Rufen Sie die Zeilenfehler ab, korrigieren Sie nur die fehlgeschlagenen Zeilen und wiederholen Sie deren Import. Alle Importaufträge sind über ihre natürliche externe ID idempotent.## Importauftrag erstellenErstellen Sie einen Importauftrag mit einer einzigen Multipart-Anfrage:```bash theme={null} curl -X POST https://verification.didit.me/v3/session/imports/ \ -H "x-api-key: YOUR_API_KEY" \ -F "import_type=user_verification" \ -F "workflow_id=YOUR_KYC_WORKFLOW_ID" \ -F "file=@didit-import.ndjson" ```Verwenden Sie CSV für kleinere, tabellenbasierte Migrationen und NDJSON für große Migrationen. Bei 100k+ Zeilen lässt sich NDJSON leichter streamen, aufteilen, validieren und wiederholen.Eine Anwendung kann bis zu 4 Importaufträge gleichzeitig ausführen. Teilen Sie große Migrationen daher auf mehrere Dateien auf und starten Sie für jede Datei einen Auftrag. Jeder Auftrag lädt die Mediendateien einer Zeile parallel herunter. Ein Auftrag, der durch ein Deployment oder einen Neustart des Workers unterbrochen wird, setzt sich automatisch ab der zuletzt importierten Zeile fort. Sie müssen ihn daher nicht neu starten.Bei Transaktionsimporten lassen Sie `workflow_id` weg:```bash theme={null} curl -X POST https://verification.didit.me/v3/session/imports/ \ -H "x-api-key: YOUR_API_KEY" \ -F "import_type=transactions" \ -F "file=@didit-transactions.ndjson" ```### Anfragefelder| Feld | Pflichtfeld | Beschreibung | | - | - | - | | `import_type` | Nein, Standard ist `user_verification` | Einer von `user_verification`, `business_verification`, `status_rules`, `transactions`. | | `workflow_id` | Ja, außer bei `transactions` | UUID des Workflows, dem die importierten Datensätze zugeordnet werden. `user_verification` und `status_rules` benötigen einen Workflow für Benutzerverifizierung; `business_verification` benötigt einen Workflow für Unternehmensverifizierung. | | `file` | Entweder `file` oder `source_file_url` | Die kanonische CSV- oder NDJSON-Datei, direkt hochgeladen. | | `source_file_url` | Entweder `file` oder `source_file_url` | HTTPS-URL, von der Didit die Datei herunterlädt. URLs aus privaten Netzwerken werden abgelehnt. | | `source_format` | Nein | `csv` oder `ndjson`. Wird bei fehlender Angabe aus der Dateiendung abgeleitet. |### Wie Datensätze erfasst und dedupliziert werdenEs gibt kein Anfragefeld für die Datenquelle: Jeder Import verwendet das kanonische Schema von Didit. Zur Nachvollziehbarkeit speichert jeder importierte Datensatz `metadata.imported_from = "generic"`.Importe mit `user_verification` und `business_verification` deduplizieren Zeilen innerhalb der Anwendung anhand von `external_id`. Ein erneuter Import derselben Datei erzeugt daher keine Duplikate. Importe mit `transactions` deduplizieren stattdessen anhand von `transaction_id`.Eine Anbieter-Migration (`source=provider`) speichert jeden Datensatz als `:`, zum Beispiel `sumsub:5f8c0e2a9b1d4c3e2f1a0b9c`. Ein Dateiimport für Benutzerverifizierung, der die reine ID des Anbieters (`5f8c0e2a9b1d4c3e2f1a0b9c`) übermittelt hat, wird als derselbe Datensatz erkannt, und zwar in beide Richtungen. Sie können daher eine Migration über Dateien beginnen und über eine Anbieter-Migration abschließen oder umgekehrt, ohne einen Datensatz doppelt zu importieren.## Import document photos, videos, and selfie evidenceBei `import_type=user_verification` können Sie die Originalfotos der Dokumente, die Videos der Dokument- und Liveness-Aufnahmen sowie das Selfie-Bild vom bisherigen Anbieter importieren.Verwenden Sie diese kanonischen Spalten:| Nachweis | Bevorzugte Spalte | Ersatz für kleine Importe | Gespeichert in Didit als | | - | - | - | - | | Dokument-Vorderseite (Bild) | `document_front_url` | `document_front_base64` | OCR-Bild der Vorderseite für die Ausweisverifizierung | | Dokument-Rückseite (Bild) | `document_back_url` | `document_back_base64` | OCR-Bild der Rückseite für die Ausweisverifizierung | | Selfie / Liveness-Bild | `selfie_url` | `selfie_base64` | Referenzbild für Gesichts- und Liveness-Erkennung | | Dokument-Vorderseite (Video) | `document_front_video_url` | nur URL | OCR-Video der Vorderseite für die Ausweisverifizierung | | Dokument-Rückseite (Video) | `document_back_video_url` | nur URL | OCR-Video der Rückseite für die Ausweisverifizierung | | Liveness-Video | `liveness_video_url` | nur URL | Aufnahmevideo für Gesichts- und Liveness-Erkennung |Für große Migrationen verwenden Sie **HTTPS-URLs**. Didit lädt jede Datei herunter, prüft, dass die URL sicher ist, speichert eine eigene Kopie bei Didit und verknüpft sie mit der importierten Sitzung. Bilder werden komprimiert; Videos werden unverändert gespeichert. Bei kleinen Importen werden Bilder auch als Base64-Inline-Daten akzeptiert, **Videos müssen jedoch immer als URL angegeben werden**. Base64 würde jedes Video um etwa 33 % vergrößern und die Obergrenze pro Datei für Importe schnell überschreiten.Beispiel für eine NDJSON-Zeile mit beim Anbieter gehosteten Medien-URLs:```json theme={null} { "external_id": "applicant-123", "vendor_data": "user-42", "created_at": "2025-01-12T10:30:00Z", "status": "Approved", "email": "user@example.com", "phone": "+34687020083", "first_name": "Jane", "last_name": "Doe", "date_of_birth": "1990-05-15", "document_type": "P", "issuing_state": "USA", "document_number": "123456789", "expiration_date": "2030-01-15", "document_front_url": "https://provider-export.example.com/files/applicant-123-front.jpg", "document_back_url": "https://provider-export.example.com/files/applicant-123-back.jpg", "selfie_url": "https://provider-export.example.com/files/applicant-123-selfie.jpg", "document_front_video_url": "https://provider-export.example.com/files/applicant-123-front.webm", "document_back_video_url": "https://provider-export.example.com/files/applicant-123-back.webm", "liveness_video_url": "https://provider-export.example.com/files/applicant-123-liveness.mp4", "reject_reasons_json": "[]", "provider_metadata_json": "{\"source\":\"sumsub-export\"}" } ```Wichtige Regeln für Medien:- URLs müssen `https` verwenden. - URLs dürfen nicht auf private IP-Adressen, localhost, Link-Local-Bereiche oder interne Metadaten-Hosts auflösen. - Bei Bildern können Sie entweder eine URL-Spalte oder die zugehörige `*_base64`-Ersatzspalte verwenden; wenn beide gesetzt sind, hat Base64 Vorrang. Videos sind nur als URL möglich. Es gibt keine Spalte `*_video_base64`. - Videos müssen `mp4`, `webm` oder `mov` sein, und jedes Video darf höchstens **10 MB** groß sein. Größere Dateien oder Dateien, die keine Videos sind, werden als Zeilenfehler abgelehnt. - Didit setzt Zeitüberschreitungen für Verbindungsaufbau und Lesevorgänge sowie eine maximale Dateigröße durch und führt keine unbegrenzten Wiederholungsversuche aus. - Fehler beim Herunterladen von Medien werden als Zeilenfehler gespeichert, damit der restliche Import fortgesetzt werden kann. - Wenn Sie keine Medien vom Anbieter haben, lassen Sie diese Spalten leer. Didit importiert trotzdem die strukturierte Entscheidung und die Dokumentfelder. - Importierte Bilder und Videos dienen als Nachweise für die historische Prüfung. Didit führt bei importierten historischen Medien standardmäßig keine OCR-, Liveness- oder Dokumentbetrugsanalyse erneut aus. Import-Prompt für Benutzerverifizierung Prompt in die Zwischenablage kopieren \

\`You are helping migrate historical User Verification (KYC) sessions into Didit.

Goal:
Transform the customer's Sumsub, MetaMap, or provider export into Didit's canonical verification import file, then call Didit's import API.

Didit API:
\- Create import job: POST https://verification.didit.me/v3/session/imports/
\- Poll job: GET https://verification.didit.me/v3/session/imports/{import_id}/
\- Read row errors: GET https://verification.didit.me/v3/session/imports/{import_id}/errors/
\- Download template: GET https://verification.didit.me/v3/session/imports/template/?import_type=user_verification
\- Authenticate with x-api-key: 

Inputs you need:
\- DIDIT_API_KEY
\- DIDIT_WORKFLOW_ID for a User Verification workflow
\- Provider export file or API output

Canonical columns:
external_id, vendor_data, created_at, status, email, phone, first_name, last_name, date_of_birth, gender, nationality, document_type, issuing_state, document_number, personal_number, expiration_date, document_front_url, document_back_url, selfie_url, document_front_base64, document_back_base64, selfie_base64, document_front_video_url, document_back_video_url, liveness_video_url, is_blocklisted, reject_reasons_json, tags, provider_metadata_json

Rules:
\- phone is optional and accepts international format (for example +34687020083); it is stored on the imported session.
\- external_id must be the provider's unique verification/applicant id.
\- vendor_data must be the customer's stable user id. If absent, use the provider identity/user id.
\- status must be Approved, Declined, In Review, or Expired.
\- date_of_birth and expiration_date must use YYYY-MM-DD.
\- created_at must be ISO 8601.
\- nationality and issuing_state must be ISO-3166 alpha-3, for example USA, ESP, BRA.
\- document_type must use Didit codes: P, ID, DL, RP, SSC, HIC, WP, TC, VISA, PSC, BC, OTHER.
\- reject_reasons_json must be a JSON array. provider_metadata_json must be a JSON object.
\- Use document_front_url, document_back_url, and selfie_url when the provider can export evidence images. Use HTTPS media URLs for large imports. Avoid inline base64 unless the import is small.
\- Use document_front_video_url, document_back_video_url, and liveness_video_url to import capture videos. Videos must be mp4, webm, or mov and at most 10 MB each; otherwise the row is rejected.
\- If only one document side exists, fill document_front_url and leave document_back_url empty.
\- Never call the import API with provider credentials. The customer downloads provider data themselves.
\- The import is idempotent by external_id inside one Didit application, so retries are safe.

Steps:
1\. Inspect the provider export schema.
2\. Map each provider row to the canonical fields.
3\. Write NDJSON for large files; one JSON object per line.
4\. Validate the first 10 rows locally before uploading.
5\. Create an import job:
curl -X POST https://verification.didit.me/v3/session/imports/ \
-H "x-api-key: $DIDIT_API_KEY" \
-F "import_type=user_verification" \
-F "workflow_id=$DIDIT_WORKFLOW_ID" \
-F "file=@didit-import.ndjson"
6\. Poll until status is COMPLETED or FAILED.
7\. If failed_count is greater than 0, fetch /errors/ and produce a corrected file containing only failed rows.

Output:
\- A canonical CSV or NDJSON file ready for Didit.
\- The curl command used to create the import job.
\- The import_id and polling command.
\- A short summary of created, skipped, and failed rows.`

\
Einfügen in Import-Prompt für Unternehmensverifizierung Prompt in die Zwischenablage kopieren \

\`You are helping migrate historical Business Verification (KYB) sessions into Didit.

Goal:
Transform the customer's KYB provider export into Didit's canonical business verification import file, then call Didit's import API.

Didit API:
\- Create import job: POST https://verification.didit.me/v3/session/imports/
\- Poll job: GET https://verification.didit.me/v3/session/imports/{import_id}/
\- Read row errors: GET https://verification.didit.me/v3/session/imports/{import_id}/errors/
\- Download template: GET https://verification.didit.me/v3/session/imports/template/?import_type=business_verification
\- Authenticate with x-api-key: 

Inputs you need:
\- DIDIT_API_KEY
\- DIDIT_WORKFLOW_ID for a Business Verification workflow
\- Provider export file or API output

Canonical business columns:
external_id, vendor_data, created_at, status, company_name, registration_number, country_code, registry_status, verification_status, company_type, tax_number, risk_level, incorporation_date, registered_address, is_from_registry, officers_json, beneficial_owners_json, provider_metadata_json, tags

Rules:
\- external_id must be the provider's unique business verification id.
\- vendor_data must be the customer's stable business id.
\- status must be Approved, Declined, In Review, or Expired.
\- country_code must be ISO-3166 alpha-3.
\- officers_json and beneficial_owners_json must be JSON arrays of objects.
\- provider_metadata_json must be a JSON object.
\- The import is idempotent by external_id inside one Didit application.

Create an import job:
curl -X POST https://verification.didit.me/v3/session/imports/ \
-H "x-api-key: $DIDIT_API_KEY" \
-F "import_type=business_verification" \
-F "workflow_id=$DIDIT_WORKFLOW_ID" \
-F "file=@didit-business-import.ndjson"

Output:
\- A canonical CSV or NDJSON file ready for Didit.
\- The curl command used to create the import job.
\- The import_id and polling command.
\- A short summary of created, skipped, and failed rows.`

\
Einfügen in Import-Prompt für benutzerdefinierte Statusregeln Prompt in die Zwischenablage kopieren \

\`You are helping import custom status rules into a Didit workflow.

Goal:
Transform the customer's policy spreadsheet into Didit's feature_status_rules format, then call Didit's import API.

Didit API:
\- Create import job: POST https://verification.didit.me/v3/session/imports/
\- Poll job: GET https://verification.didit.me/v3/session/imports/{import_id}/
\- Read row errors: GET https://verification.didit.me/v3/session/imports/{import_id}/errors/
\- Download template: GET https://verification.didit.me/v3/session/imports/template/?import_type=status_rules
\- Authenticate with x-api-key: 

Inputs you need:
\- DIDIT_API_KEY
\- DIDIT_WORKFLOW_ID for the workflow to update
\- A policy spreadsheet or JSON policy definition

Canonical status-rule columns:
feature, rules_json, mode

Rules:
\- feature must be a Didit feature key such as OCR, LIVENESS, FACE_MATCH, AML, KYB_REGISTRY, KYB_DOCUMENTS, or KYB_KEY_PEOPLE.
\- rules_json must be a JSON array of rule objects.
\- Each rule needs field, operator, status, and usually value.
\- mode is replace or append. Default is replace.
\- Do not reference status fields such as kyc.status; status rules compute status and must use other report fields.

Example rules_json:
\[{"field":"kyc.issuing_state","operator":"in","value":["VEN","IRN"],"status":"In Review"}]

Create an import job:
curl -X POST https://verification.didit.me/v3/session/imports/ \
-H "x-api-key: $DIDIT_API_KEY" \
-F "import_type=status_rules" \
-F "workflow_id=$DIDIT_WORKFLOW_ID" \
-F "file=@didit-status-rules.csv"

Output:
\- A canonical CSV or NDJSON file ready for Didit.
\- The curl command used to create the import job.
\- The import_id and polling command.
\- A summary of updated and failed rule rows.`

\
Einfügen in Import-Prompt für Transaktionen Prompt in die Zwischenablage kopieren \

\`You are helping migrate historical transaction monitoring records into Didit.

Goal:
Transform the customer's legacy transaction monitoring export into Didit's canonical transaction import file, then call Didit's import API.

Didit API:
\- Create import job: POST https://verification.didit.me/v3/session/imports/
\- Poll job: GET https://verification.didit.me/v3/session/imports/{import_id}/
\- Read row errors: GET https://verification.didit.me/v3/session/imports/{import_id}/errors/
\- Download template: GET https://verification.didit.me/v3/session/imports/template/?import_type=transactions
\- Authenticate with x-api-key: 

Inputs you need:
\- DIDIT_API_KEY
\- A transaction export file or API output

Canonical transaction columns:
transaction_id, transaction_at, transaction_category, direction, amount, currency, currency_kind, amount_in_default_currency, default_currency, payment_details, payment_reference_id, action_type, status, score, severity, subject_json, counterparty_json, custom_properties_json, provider_results_json, travel_rule_json, network_snapshot_json, metadata_json

Rules:
\- transaction_id is required and is idempotent per Didit application.
\- transaction_category must be one of Didit's transaction categories, for example finance, kyc, travelRule, userPlatformEvent, gamblingBet, gamblingLimitChange, gamblingBonusChange, or auditTrailEvent.
\- direction must be INBOUND or OUTBOUND.
\- status must be APPROVED, IN_REVIEW, DECLINED, or AWAITING_USER.
\- subject_json must include vendor_data and full_name.
\- counterparty_json is optional but should be included when the legacy provider has it.
\- provider_results_json must be a JSON array.
\- travel_rule_json, network_snapshot_json, custom_properties_json, and metadata_json must be JSON objects when present.

Create an import job:
curl -X POST https://verification.didit.me/v3/session/imports/ \
-H "x-api-key: $DIDIT_API_KEY" \
-F "import_type=transactions" \
-F "file=@didit-transactions.ndjson"

Output:
\- A canonical CSV or NDJSON file ready for Didit.
\- The curl command used to create the import job.
\- The import_id and polling command.
\- A summary of created, skipped, and failed transaction rows.`

\
Einfügen in ## Fortschritt abfragen```bash theme={null} curl https://verification.didit.me/v3/session/imports/IMPORT_ID/ \ -H "x-api-key: YOUR_API_KEY" ```Die Antwort enthält `status`, `import_type`, `total_rows`, `processed_rows`, `created_count`, `updated_count`, `skipped_count`, `failed_count` und `checkpoint_row`.## Zeilenfehler herunterladen```bash theme={null} curl https://verification.didit.me/v3/session/imports/IMPORT_ID/errors/ \ -H "x-api-key: YOUR_API_KEY" ```Jeder Fehler enthält `row_number`, `external_id`, `error` und `raw_row`, damit Sie nur die fehlgeschlagenen Zeilen korrigieren und erneut ausführen können.## Schutz vor MissbrauchHistorische Import-Jobs über `POST /v3/session/imports/` sind standardmäßig deaktiviert. Didit aktiviert diese Funktion nach einer Prüfung pro Organisation, weil solche Jobs Millionen Zeilen verarbeiten und Medien herunterladen können. Die regulären Betriebsdatenimporte in dieser Anleitung, also das Anlegen von Benutzern und Unternehmen, das Hochladen von Profilgesichtern und Gesichts-Sperrlisten sowie das Hinzufügen von Listeneinträgen, erfordern über die normalen API-Schlüssel-Berechtigungen, die Produktverfügbarkeit und die Rate-Limits dieser Endpunkte hinaus keine besondere Freischaltung für Migrationen.Historische Import-Jobs laufen außerdem auf isolierten Workern mit Dateigrößenbeschränkungen, Zeilenbudgets, nur HTTPS-Medien-URLs, Blockierung privater Netzwerk-URLs, einem Limit von 4 aktiven Import-Jobs pro Anwendung und einer Erfassung von Fehlern pro Zeile.## Kanonische Statuswerte| Ergebnis des Anbieters | Didit-Status | | - | - | | Genehmigt / Grün / Verifiziert | `Approved` | | Abgelehnt / Rot / Zurückgewiesen | `Declined` | | Manuelle Prüfung / Ausstehend / Überprüfung erforderlich | `In Review` | | Unvollständig / Init / Unbekannte historische Zeile | `Expired` |## IdempotenzDidit verwendet `external_id` als Idempotenz-Schlüssel für Importe von Benutzerverifizierungen und Unternehmensverifizierungen, jeweils bezogen auf die Anwendung. Transaktionsimporte verwenden `transaction_id` pro Anwendung. Wenn Sie dieselbe Datei erneut ausführen, werden bereits importierte Zeilen übersprungen und noch nicht verarbeitete Zeilen angelegt.## Benutzer, Profilgesichter und Sperrlisten importierenVerwenden Sie diese Wege, wenn Sie keine abgeschlossene Verifizierungssitzung nachbilden möchten:### Benutzerprofile importierenLegen Sie Benutzer mit [`POST /v3/users/create/`](https://docs.didit.me/de/management-api/users/create) oder über den CSV-Import in der Business Console an, siehe [„Benutzer importieren und exportieren“](https://docs.didit.me/de/entities/users/import-export.md). Dabei wird nur das `VendorUser`-Profil erstellt oder aktualisiert. Es wird keine Verifizierungssitzung, KYC-Entscheidung, kein Dokumentenbericht, keine Warnung und kein Webhook-Verlauf erstellt.Das ist sinnvoll, wenn Didit den Kunden bereits kennen soll, bevor künftige Prüfungen stattfinden, oder wenn Sie CRM-ähnliche Felder wie `display_name`, Tags oder Metadaten nachträglich befüllen müssen.### Vertrauenswürdige Profilgesichter hochladenNachdem ein Benutzer angelegt wurde, laden Sie mit [`POST /v3/organization/{organization_id}/application/{application_id}/vendor-users/by-id/{didit_internal_id}/faces/upload/`](https://docs.didit.me/de/management-api/users/upload-face) ein vertrauenswürdiges Gesicht für das Profil hoch. Dadurch werden die biometrischen Daten dem Benutzerprofil zugeordnet und für die Duplikatserkennung und die Gesichtssuche indexiert.Damit wird das Gesicht **nicht** auf die Sperrliste gesetzt. Die Funktion eignet sich, wenn Sie ein vertrauenswürdiges Profilbild von einem bisherigen KYC-Anbieter haben und möchten, dass künftige Didit-Prüfungen damit abgeglichen werden.### Gesichts-Sperrlisten und Allowlists importierenUm ein Gesicht direkt zu sperren oder freizugeben, verwenden Sie [`POST /v3/lists/{list_uuid}/entries/face-upload/`](https://docs.didit.me/de/management-api/lists/upload-face) mit einer Liste vom Typ „Gesicht“. Didit extrahiert das biometrische Embedding und speichert einen Listeneintrag.Das eignet sich für bekannte Betrüger-Fotos, vertrauenswürdige Gesichter auf der Allowlist oder die Migration von Betrugslisten von Anbietern. Stammt das Gesicht aus einer bestehenden Didit-Sitzung, verwenden Sie bevorzugt [`POST /v3/lists/{list_uuid}/entries/`](https://docs.didit.me/de/management-api/lists/create-entry) mit `reference_session_id`. Didit extrahiert dann das passende Gesicht aus der Sitzung und verknüpft den Eintrag mit der Quelle.### Listen für Benutzer, Unternehmen, Dokumente, Wallets, E-Mail-Adressen, Telefonnummern, IP-Adressen oder Geräte importierenFür Listenwerte, die keine Gesichter sind, verwenden Sie [`POST /v3/lists/{list_uuid}/entries/`](https://docs.didit.me/de/management-api/lists/create-entry). Dieser Weg ist richtig für Sperrlisten, Allowlists und Chargeback-Listen von Anbietern sowie für Adressen von Wallets, bekannte riskante IP-Adressen, Geräte-Fingerprints, Dokumentnummern, E-Mail-Adressen, Telefonnummern, Benutzer oder Unternehmen.## Nächste Schritte> [card] [Benutzer importieren](https://docs.didit.me/de/entities/users/import-export.md) > > Benutzerprofile laden und vertrauenswürdige Profilgesichter zuordnen.> [card] [Unternehmen importieren](https://docs.didit.me/de/entities/businesses/import-export.md) > > Unternehmensprofile laden, bevor Sie KYB durchführen.> [card] [Profilgesicht hochladen](https://docs.didit.me/de/management-api/users/upload-face.md) > > Vertrauenswürdige Gesichtsbilder importierten Benutzern zuordnen.> [card] [Gesicht in Liste hochladen](https://docs.didit.me/de/management-api/lists/upload-face.md) > > Gesichter zu Sperrlisten oder Allowlists hinzufügen.> [card] [Listeneintrag erstellen](https://docs.didit.me/de/management-api/lists/create-entry.md) > > Telefonnummern, E-Mail-Adressen, Wallets, Dokumente, IP-Adressen, Geräte, Benutzer oder Unternehmen in Listen importieren.> [card] [Rate-Limits](https://docs.didit.me/de/integration/rate-limiting.md) > > Sichere Migrationsschleifen und Wiederholungsversuche gestalten. ## OpenAPI ````yaml de/openapi-25.json POST /v3/session/imports/ openapi: 3.0.0 info: version: 3.0.0 title: Didit Verification API description: API für Ausweisverifizierung. Authentifizierung über den x-api-key-Header. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/session/imports/: post: tags: - Sessions summary: Erstellen Sie einen Verifizierungs-Importauftrag description: >- Erstellt einen asynchronen Importauftrag für historische Benutzerverifizierungs-Sitzungen, Unternehmensverifizierungs-Sitzungen, Transaktionsüberwachungs-Datensätze oder benutzerdefinierte Workflow-Statusregeln. Setzen Sie `source=provider`, um von einem anderen Anbieter zu migrieren: Didit liest Sumsub, Onfido, Persona und ComplyCube mit Ihrem Nur-Lese-Schlüssel aus, liest Datensätze von Veriff, iDenfy und MetaMap anhand der IDs aus, die Sie in `file` hochladen, und importiert für andere Anbieter eine Exportdatei im Didit-Format. Datensatz-IDs erhalten einen Namespace nach Anbieter (`sumsub:`), sodass ein erneuter Durchlauf alles überspringt, was bereits in Didit vorhanden ist. Zudem wird ein Datensatz, der über eine Datei mit der reinen Anbieter-ID importiert wurde, in beiden Richtungen erkannt, sodass beim Wechsel zwischen einem Datei-Import und einer Anbietermigration niemals ein Datensatz doppelt importiert wird. Eine Anwendung kann bis zu 4 Importaufträge gleichzeitig ausführen; ein durch ein Deployment oder einen Worker-Neustart unterbrochener Auftrag wird automatisch ab der zuletzt importierten Zeile fortgesetzt. Importe sind standardmäßig deaktiviert und müssen pro Organisation von Didit freigeschaltet werden. operationId: post_v3_session_imports_create requestBody: required: true content: multipart/form-data: schema: type: object properties: import_type: type: string enum: - user_verification - business_verification - status_rules - transactions default: user_verification description: >- Was importiert werden soll: historische Sitzungen der Benutzerverifizierung, historische Sitzungen der Unternehmensverifizierung, benutzerdefinierte Statusregeln für Workflows oder historische Datensätze der Transaktionsüberwachung. workflow_id: type: string format: uuid description: >- Workflow-UUID, mit der importierte Sitzungen oder Statusregeln verknüpft werden sollen. Erforderlich für user_verification, business_verification und status_rules. Bei Transaktionen weglassen. source_format: type: string enum: - csv - ndjson description: >- Optional. Wird anhand der Dateiendung der hochgeladenen Datei abgeleitet, wenn sie weggelassen wird. file: type: string format: binary description: >- Kanonische CSV- oder NDJSON-Datei. Verwenden Sie NDJSON für große Importe. Maximale Upload-Größe 25 MB (verwenden Sie `source_file_url` für größere Dateien). Ist mit `source_file_url` nicht kombinierbar. source_file_url: type: string format: uri description: >- Alternative zum Datei-Upload. Muss eine HTTPS-URL sein, die auf eine öffentliche Adresse auflöst (private/Loopback-Netzwerke werden abgelehnt). Schließt sich mit `file` gegenseitig aus. source: type: string enum: - file - provider description: >- `provider` kennzeichnet dies als Migration von einem anderen Anbieter für Ausweisverifizierung. Für einen Datei-Import weglassen. provider: type: string enum: - sumsub - jumio - veriff - onfido - persona - metamap - socure - idnow - shufti - idenfy - ondato - trulioo - au10tix - complycube - other description: >- Migrationsquelle, aus `GET /v3/session/imports/providers/`. Erforderlich, wenn `source` den Wert `provider` hat. credentials: type: object additionalProperties: type: string description: >- Der schreibgeschützte Schlüssel des Anbieters mit den von `credential_fields` aufgelisteten Feldnamen. Im Ruhezustand verschlüsselt, wird niemals zurückgegeben und nach Abschluss des Imports gelöscht. Senden Sie ihn als JSON-String in multipart. options: type: object properties: region: type: string description: >- Die Region des Anbieters, eine seiner `regions` (Onfido: `eu`, `us`, `ca`). status_mapping: type: object additionalProperties: type: string enum: - Approved - Declined - In Review - Expired - Not Finished - Abandoned description: >- Anpassungen des Standard-Status-Mappings des Anbieters: Quellstatus zu Didit-Status. `Not Finished` und `Abandoned` werden übersprungen und gezählt, jedoch niemals importiert. dry_run: type: boolean default: false description: >- Zählen, was die Migration importieren würde (nach Status, bereits in Didit, dieselbe Person, nicht abgeschlossen) und nichts schreiben. Der Auftrag endet als `READY`; starten Sie ihn mit `POST /v3/session/imports/{importId}/start/`. face_templates: type: boolean default: false description: >- Erstellen Sie biometrische Templates aus den importierten Selfies und gleichen Sie diese mit den Gesichtern und der Sperrliste der Anwendung ab. Übereinstimmungen werden nur zur Prüfung markiert. Erfordert `lawful_basis_confirmed`. lawful_basis_confirmed: type: boolean default: false description: >- Bestätigt, dass Sie über eine Rechtsgrundlage verfügen, um diese Selfies mit Didit als Auftragsverarbeiter zu teilen. application/json: schema: type: object required: - source_file_url properties: import_type: type: string enum: - user_verification - business_verification - status_rules - transactions default: user_verification description: >- Was importiert werden soll: historische Sitzungen der Benutzerverifizierung, historische Sitzungen der Unternehmensverifizierung, benutzerdefinierte Statusregeln für Workflows oder historische Datensätze der Transaktionsüberwachung. workflow_id: type: string format: uuid description: >- Workflow-UUID, mit der importierte Sitzungen oder Statusregeln verknüpft werden sollen. Erforderlich für user_verification, business_verification und status_rules. Bei Transaktionen weglassen. source_format: type: string enum: - csv - ndjson description: >- Optional. Wird anhand der Dateiendung der URL abgeleitet, wenn sie weggelassen wird. source_file_url: type: string format: uri description: >- Alternative zum Datei-Upload. Muss eine HTTPS-URL sein, die auf eine öffentliche Adresse auflöst (private/Loopback-Netzwerke werden abgelehnt). Schließt sich mit `file` gegenseitig aus. source: type: string enum: - file - provider description: >- `provider` kennzeichnet dies als Migration von einem anderen Anbieter für Ausweisverifizierung. Für einen Datei-Import weglassen. provider: type: string enum: - sumsub - jumio - veriff - onfido - persona - metamap - socure - idnow - shufti - idenfy - ondato - trulioo - au10tix - complycube - other description: >- Migrationsquelle, aus `GET /v3/session/imports/providers/`. Erforderlich, wenn `source` den Wert `provider` hat. credentials: type: object additionalProperties: type: string description: >- Der schreibgeschützte Schlüssel des Anbieters mit den von `credential_fields` aufgelisteten Feldnamen. Im Ruhezustand verschlüsselt, wird niemals zurückgegeben und nach Abschluss des Imports gelöscht. Senden Sie ihn als JSON-String in multipart. options: type: object properties: region: type: string description: >- Die Region des Anbieters, eine seiner `regions` (Onfido: `eu`, `us`, `ca`). status_mapping: type: object additionalProperties: type: string enum: - Approved - Declined - In Review - Expired - Not Finished - Abandoned description: >- Anpassungen des Standard-Status-Mappings des Anbieters: Quellstatus zu Didit-Status. `Not Finished` und `Abandoned` werden übersprungen und gezählt, jedoch niemals importiert. dry_run: type: boolean default: false description: >- Zählen, was die Migration importieren würde (nach Status, bereits in Didit, dieselbe Person, nicht abgeschlossen) und nichts schreiben. Der Auftrag endet als `READY`; starten Sie ihn mit `POST /v3/session/imports/{importId}/start/`. face_templates: type: boolean default: false description: >- Erstellen Sie biometrische Templates aus den importierten Selfies und gleichen Sie diese mit den Gesichtern und der Sperrliste der Anwendung ab. Übereinstimmungen werden nur zur Prüfung markiert. Erfordert `lawful_basis_confirmed`. lawful_basis_confirmed: type: boolean default: false description: >- Bestätigt, dass Sie über eine Rechtsgrundlage verfügen, um diese Selfies mit Didit als Auftragsverarbeiter zu teilen. examples: URL-based import: value: import_type: user_verification workflow_id: 9f9b1234-aaaa-bbbb-cccc-1234567890ab source_file_url: https://files.example.com/exports/sessions.ndjson responses: '201': description: >- Import-Job akzeptiert. Fragen Sie die zurückgegebene `uuid` regelmäßig ab, bis der `status` `COMPLETED` oder `FAILED` lautet. content: application/json: schema: $ref: '#/components/schemas/SessionImportJob' examples: Job accepted: value: uuid: 3f9c1a2b-4d5e-4f60-8a7b-9c0d1e2f3a4b status: PENDING import_type: user_verification source_format: ndjson source_filename: sessions.ndjson total_rows: 0 processed_rows: 0 checkpoint_row: 0 created_count: 0 updated_count: 0 skipped_count: 0 failed_count: 0 total_media_bytes: 0 last_error: null created_at: '2026-05-17T08:42:11Z' updated_at: '2026-05-17T08:42:11Z' started_at: null completed_at: null '400': description: >- Ungültiger Workflow, Dateityp, Dateigröße, Quell-URL oder Selektorkombination. Eine Migration, deren Schlüssel der Anbieter ablehnt, gibt `code` (`invalid_credentials`, `missing_permission`, `wrong_region`, `provider_unavailable`, `rate_limited`, `ids_required`, `record_not_found`), `missing_permissions` und `suggested_region` zurück. content: application/json: examples: Invalid workflow: value: workflow_id: - Invalid workflow_id. Workflow required: value: workflow_id: - This field is required for this import type. Wrong file type: value: file: - Only CSV and NDJSON files are supported. File too large: value: file: - Import file exceeds the maximum allowed size. No source: value: file: - Upload a file or provide source_file_url. Both sources: value: file: - Use either file or source_file_url, not both. '403': description: >- Importe nicht aktiviert, Sandbox-Anwendung oder fehlender API-Schlüssel (ein falscher, widerrufener oder abgelaufener Schlüssel führt zu `401`). Verifizierungsimporte sind standardmäßig deaktiviert und müssen von Didit pro Organisation aktiviert werden. content: application/json: examples: Imports not enabled: value: detail: >- Verification imports are not enabled for this organization. Sandbox: value: detail: >- Verification imports are not enabled for sandbox applications. Bad API key: value: detail: You do not have permission to perform this action. '429': description: >- Die Anwendung hat bereits 4 aktive Import-Jobs (PENDING/PROCESSING/PAUSED) – das Maximum, das gleichzeitig ausgeführt werden kann. Warten Sie, bis einer abgeschlossen ist, bevor Sie einen weiteren starten. content: application/json: examples: Active job: value: detail: >- This application already has 4 active import jobs, the most it can run at once. Wait for one to finish before starting another. security: - ApiKeyAuth: [] x-codeSamples: - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.sessions.imports.create( import_type="user_verification", workflow_id="9f9b1234-aaaa-bbbb-cccc-1234567890ab", source_file_url="https://files.example.com/exports/sessions.ndjson", ) print(result) - lang: javascript label: Node.js source: |- import Didit from "@didit-protocol/sdk-node"; // Reads DIDIT_API_KEY. const didit = new Didit(); const result = await didit.sessions.imports.create({ import_type: "user_verification", workflow_id: "9f9b1234-aaaa-bbbb-cccc-1234567890ab", source_file_url: "https://files.example.com/exports/sessions.ndjson", }); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Sessions.Imports.Create(ctx, didit.SessionsImportsCreateParams{\n\tImportType: didit.Some(didit.SessionsImportsCreateParamsImportType(\"user_verification\")),\n\tWorkflowID: didit.String(\"9f9b1234-aaaa-bbbb-cccc-1234567890ab\"),\n\tSourceFileURL: didit.String(\"https://files.example.com/exports/sessions.ndjson\"),\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)" - lang: java label: Java source: >- import me.didit.Didit; import me.didit.types.SessionsImportsCreateParams; // Reads DIDIT_API_KEY. Didit client = new Didit(); var result = client.sessions().imports().create(SessionsImportsCreateParams.builder() .importType(SessionsImportsCreateParams.ImportType.of("user_verification")) .workflowId("9f9b1234-aaaa-bbbb-cccc-1234567890ab") .sourceFileUrl("https://files.example.com/exports/sessions.ndjson") .build()); System.out.println(result); - lang: php label: PHP source: |- sessions->imports->create([ 'import_type' => 'user_verification', 'workflow_id' => '9f9b1234-aaaa-bbbb-cccc-1234567890ab', 'source_file_url' => 'https://files.example.com/exports/sessions.ndjson', ]); print_r($result->toArray()); - lang: ruby label: Ruby source: |- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.sessions.imports.create( import_type: "user_verification", workflow_id: "9f9b1234-aaaa-bbbb-cccc-1234567890ab", source_file_url: "https://files.example.com/exports/sessions.ndjson" ) puts result.to_h - lang: csharp label: .NET source: >- using System; using System.Text.Json; using Didit; // Reads DIDIT_API_KEY. using var client = new DiditClient(); var result = await client.Sessions.Imports.CreateAsync(new SessionsImportsCreateParams { ImportType = new SessionsImportsCreateParamsImportType("user_verification"), WorkflowId = "9f9b1234-aaaa-bbbb-cccc-1234567890ab", SourceFileUrl = "https://files.example.com/exports/sessions.ndjson", }); Console.WriteLine(JsonSerializer.Serialize(result)); components: schemas: SessionImportJob: type: object required: - uuid - status - import_type - source_format - source_filename - total_rows - processed_rows - created_count - updated_count - skipped_count - failed_count properties: uuid: type: string format: uuid description: >- ID des Import-Jobs. Verwenden Sie diesen Wert, um den Fortschritt abzufragen und Zeilenfehler abzurufen. status: type: string enum: - PENDING - PROCESSING - COMPLETED - FAILED - PAUSED - CANCELLED - READY import_type: type: string enum: - user_verification - business_verification - status_rules - transactions source_format: type: string enum: - csv - ndjson source_filename: type: string total_rows: type: integer format: int64 processed_rows: type: integer format: int64 checkpoint_row: type: integer format: int64 created_count: type: integer format: int64 updated_count: type: integer format: int64 skipped_count: type: integer format: int64 failed_count: type: integer format: int64 total_media_bytes: type: integer format: int64 last_error: type: string nullable: true created_at: type: string format: date-time updated_at: type: string format: date-time started_at: type: string format: date-time nullable: true completed_at: type: string format: date-time nullable: true state: type: string enum: - ready - queued - running - paused - completed - errors - failed - cancelled description: >- Der Status des Jobs, wie er in der Konsole angezeigt wird; `errors` ist ein abgeschlossener Job mit abgelehnten Zeilen. source: type: string enum: - file - api - provider provider: type: string description: Migrationsquelle; leer bei einem Datei- oder API-Import. provider_options: type: object credential_hint: type: string description: >- Die ersten Zeichen des Schlüssels, den die Migration enthält. Der Schlüssel selbst wird niemals zurückgegeben. credentials_expires_at: type: string format: date-time nullable: true resumes_at: type: string format: date-time nullable: true description: >- Wenn ein durch das Rate-Limit des Anbieters pausierter Auftrag von selbst fortgesetzt wird. status_mapping: type: object additionalProperties: type: string is_dry_run: type: boolean dry_run_summary: type: object description: >- Was ein Testlauf ergeben hat: `total`, `by_status`, `already_in_didit`, `same_person`, `not_finished`, `failed`, `unmapped_statuses`. face_templates_enabled: type: boolean lawful_basis_confirmed_at: type: string format: date-time nullable: true not_finished_count: type: integer format: int64 same_person_count: type: integer format: int64 face_templates_count: type: integer format: int64 face_duplicates_count: type: integer format: int64 face_blocklist_hits_count: type: integer format: int64 created_by_name: type: string nullable: true created_by_email: type: string nullable: true securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- Der API-Schlüssel Ihrer Anwendung, aus Entwickler -> API-Schlüssel in der Business Console. Der Primärschlüssel hat Vollzugriff. Ein benannter Schlüssel kann im Geltungsbereich eingeschränkt werden: keine, Lese- oder Schreibberechtigung pro Ressource, beschränkt auf bestimmte Workflows oder genehmigte Sitzungen, auf eine Liste von IP-Adressen und auf ein Ablaufdatum. 401 bedeutet, dass der Schlüssel falsch, widerrufen oder abgelaufen ist; 403 bedeutet, dass kein Schlüssel gesendet wurde, der Schlüssel keinen Zugriff auf diese Ressource oder Aktion hat oder die Anfrage von einer Adresse außerhalb seiner IP-Liste stammte; 404 bei einer Sitzungsroute bedeutet, dass die Sitzung außerhalb der Workflows oder Status des Schlüssels liegt. Ein Schlüssel ohne Medienzugriff erhält Bild-, Video- und PDF-URLs als null, und ein Schlüssel ohne Schreibberechtigung für Sitzungen erhält Sitzungslinks und Token als null. Siehe https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.