> ## 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. # Kundennachrichten im Fallmanagement > Didit: Feste Nachrichten vorab ansehen, Informationen von einem verifizierten Kontakt anfordern und Antworten von Kunden prüfen. Öffnen Sie einen Fall und wählen Sie **Nachricht senden**. Wählen Sie einen verifizierten Empfänger, eine Sprache und den Zweck und klicken Sie anschließend auf **Vorschau**. Die Vorschau zeigt den genauen Absender, Empfänger, Betreff und E-Mail-Text. Wählen Sie **Bearbeiten**, um die Auswahl zu ändern, oder **Senden**, um sie zu bestätigen. Eine geänderte oder abgelaufene Vorschau muss vor dem Senden neu erstellt werden. ## Nachrichtenzwecke | Zweck | Aktion des Kunden | Fallstatus | | - | - | - | | Ausweisdokument | Ein deutliches Foto eines Ausweisdokuments hochladen | Warten auf Benutzer | | Adressnachweis | Ein aktuelles Dokument hochladen, das Name und Wohnadresse zeigt | Warten auf Benutzer | | Unternehmensdokument | Ein Dokument zur Unternehmensregistrierung hochladen | Warten auf Benutzer | | Angaben bestätigen | Vollständigen Namen und Geburtsdatum übermitteln, damit der Prüfer sie bewerten kann | Warten auf Benutzer | | Prüfung läuft | Keine Aktion erforderlich; die E-Mail enthält keine Antwortschaltfläche | Unverändert | Dokument-Uploads akzeptieren derzeit JPEG-, PNG- und WebP-Bilder bis 5 MB. Nur die Zwecke, die auf die betroffene Person im Fall zutreffen, werden angezeigt. Kunden-E-Mail-Vorlagen sind derzeit auf Englisch, Spanisch und Portugiesisch verfügbar. Die Konsole verwendet dasselbe E-Mail-Feld und dieselbe Sprachauswahl wie die erneute Einreichung der Sitzung. ## Verifizierte Empfänger und feste Vorlagen Ein Empfänger muss die E-Mail-Verifizierung in einer Sitzung abgeschlossen haben, die der betroffenen Person im Fall und der Anwendung zugeordnet ist. Eine Adresse, die in einem Benutzerprofil importiert oder bearbeitet wurde, begründet keine Verifizierung. Gibt es keinen verifizierten Kontakt, erklärt der Editor dies, und das Senden bleibt deaktiviert. Prüfer können keine beliebigen E-Mail-Texte, Links, Absenderadressen oder Empfänger angeben. Die E-Mail verwendet das bestehende Didit- oder White-Label-Branding. Ein benutzerdefinierter Absender erfordert, dass die konfigurierte E-Mail-Domain verifiziert ist. Jede Vorlage weist den Empfänger darauf hin, dass die E-Mail keine Passwörter, Verifizierungscodes oder Zahlungen anfordert. Das erneute Einreichen einer Sitzung bleibt eine separate Aktion zur Wiederholung von Verifizierungsprüfungen. Die Vorschau zeigt die tatsächliche E-Mail zur erneuten Einreichung und die ausgewählten Prüfungen. ## Zustellung und Antworten Der Nachrichtenverlauf unterscheidet die Zustellergebnisse „in der Warteschlange“, „wird gesendet“, „gesendet“, „simuliert“ und „unbekannt“. Eine simulierte E-Mail wird nicht gesendet. Ein unbekanntes Ergebnis bedeutet, dass der Anbieter die E-Mail möglicherweise angenommen hat; das System sendet sie nicht automatisch erneut. Beim erneuten Versuch einer bestätigten Anfrage wird dieselbe Anfrage-ID verwendet, um doppelte Zustellung zu vermeiden. Eine Anfrage, die eine Antwort erfordert, hat einen sicheren Antwort-Link, der sieben Tage gültig ist. Das Abbrechen der Anfrage oder das Abschließen des Falls macht diesen Link ungültig, auch nachdem ein Fall wieder geöffnet wurde. Die Kundenseite gibt keine nicht öffentlichen Ergebnisse des Falls und keine anderen Quelldatensätze preis. Eine übermittelte Antwort erscheint unter **Kundennachrichten** als Nachweis, dessen Prüfung aussteht. Der Fall wird wieder auf Offen gesetzt, und eine bestehende ausstehende Entscheidung muss erneut geprüft werden. Antworten können eine frühere Einreichung nicht ersetzen, die ursprüngliche Verifizierung nicht genehmigen, die Identität eines Kunden nicht überschreiben und nicht zu einem Ergebnis der Betrugsbewertung beitragen. Das Löschen der zugrunde liegenden Verifizierung oder des Falls löscht auch die zugehörigen Kundenanfragen und deren hochgeladene Nachweise. ## API-Workflow Alle Konsolen-Endpoints sind auf eine Organisation, eine Anwendung und einen Fall beschränkt: ```text theme={null} GET /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/options/ POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/preview/ GET /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/ POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/ POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/cancel/ POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/remind/ GET /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/attachment/ ``` Zum Lesen des Verlaufs und der Anhänge ist `read:cases` erforderlich. Zum Verfassen, Anzeigen der Vorschau, Bestätigen, Abbrechen und Erinnern ist `write:cases` erforderlich. Die Bestätigung muss dieselben `contact_id`, `purpose` und `language` enthalten sowie `request_id`, `expires_at` und `preview_token`, die von der Vorschau zurückgegeben wurden. Der Bestätigungsnachweis läuft nach 15 Minuten ab, unabhängig von der Antwortfrist des Kunden. Eine Erinnerung sendet dieselbe E-Mail erneut an denselben verifizierten Empfänger, höchstens einmal pro Anfrage alle 24 Stunden. Sonst ändert sich nichts: Die Anfrage behält ihre Frist und der Fall behält seinen Status. Die Antwort enthält die Anfrage, `reminded_at`, den eigenen `delivery_status` der Erinnerung (`SENT`, `SIMULATED` oder `UNKNOWN`) und `next_reminder_at`. Eine Anfrage, auf die der Kunde nicht mehr antworten muss, gibt `409` mit `code` `case_request_not_waiting` und einem `reason` zurück: `answered`, `cancelled`, `expired`, `closed`, `not_actionable`, `not_delivered` oder `contact_unavailable`. Eine zweite Erinnerung innerhalb von 24 Stunden gibt `429` mit `code` `case_request_reminder_too_soon`, einem Zeitstempel `retry_at` und dem Header `Retry-After` zurück. Solange eine Entscheidung auf Genehmigung wartet, gibt eine Erinnerung `400` zurück. Der Kunden-Endpoint ist `GET` oder `POST /v3/case-requests/{request_uuid}/` mit dem anfragespezifischen Header `X-Case-Request-Token`. Der Antwort-Link enthält dieses Zugriffstoken in seinem Fragment; die Seite entfernt das Fragment beim Öffnen. Das Token gewährt nur Zugriff auf diese Anfrage. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.