Commencer
Intégrer / SDK
Vérification des utilisateurs
Vérification d'entreprise
Surveillance des transactions
Journal des modificationsFinalités des messages
Les téléversements de documents acceptent actuellement les images JPEG, PNG et WebP jusqu’à 5 MB.
Seules les finalités applicables à la personne concernée par le dossier apparaissent.
Les modèles d’e-mail destinés aux clients sont actuellement disponibles en anglais, en espagnol et en portugais.
La console utilise le même champ e-mail et le même sélecteur de langue que la nouvelle soumission de session.
Destinataires vérifiés et modèles fixes
Un destinataire doit avoir terminé la vérification de l’e-mail lors d’une session appartenant à la personne concernée par le dossier et à l’application. Une adresse importée ou modifiée dans un profil utilisateur n’établit pas la vérification. S’il n’existe aucun contact vérifié, l’éditeur de message l’indique et l’envoi reste désactivé. Les réviseurs ne peuvent pas fournir de texte d’e-mail, de liens, d’adresses d’expéditeur ou de destinataires arbitraires. L’e-mail utilise la marque Didit existante ou la marque blanche. Un expéditeur personnalisé nécessite que le domaine d’e-mail configuré soit vérifié. Chaque modèle indique au destinataire que l’e-mail ne demandera ni mots de passe, ni codes de vérification, ni paiement. La nouvelle soumission de session reste une action distincte, qui permet de répéter les contrôles de vérification. Son aperçu affiche l’e-mail de nouvelle soumission réel et les contrôles sélectionnés.Envoi et réponses
L’historique des messages distingue les états de livraison suivants : en file d’attente, en cours d’envoi, envoyé, simulé et inconnu. Un e-mail simulé n’est pas envoyé. Un résultat inconnu signifie que le fournisseur a peut-être accepté l’e-mail ; le système ne le renvoie pas automatiquement. Pour réessayer une requête confirmée, on utilise le même identifiant de requête afin d’éviter une double livraison. Une requête à laquelle le client peut répondre dispose d’un lien de réponse sécurisé valable sept jours. L’annulation de la requête ou la résolution du dossier invalide ce lien, y compris après la réouverture du dossier. La page client ne divulgue ni les conclusions privées du dossier ni les autres enregistrements sources. Une réponse soumise apparaît dans Messages au client comme élément de preuve en attente d’examen. Le dossier repasse à Ouvert, et une résolution en attente existante doit être réexaminée. Les réponses ne peuvent pas remplacer une soumission antérieure, approuver la vérification initiale, écraser l’identité d’un client ni contribuer à une conclusion de fraude. La suppression de la vérification source ou du dossier supprime ses requêtes client et les pièces justificatives téléversées.Workflow API
Tous les endpoints de la console sont limités à une organisation, une application et un dossier :read:cases.
La rédaction, la prévisualisation, la confirmation, l’annulation et le rappel nécessitent write:cases.
La confirmation doit inclure les mêmes contact_id, purpose et language, ainsi que request_id, expires_at et preview_token renvoyés par l’aperçu.
Le reçu de confirmation expire au bout de 15 minutes, indépendamment de la date limite de réponse du client.
Un rappel renvoie le même e-mail au même destinataire vérifié, au plus une fois par requête toutes les 24 heures.
Il ne modifie rien d’autre : la requête conserve sa date limite et le dossier conserve son statut.
La réponse renvoie la requête, reminded_at, le delivery_status propre au rappel (SENT, SIMULATED ou UNKNOWN) et next_reminder_at.
Une requête à laquelle le client n’a plus à répondre renvoie 409 avec code case_request_not_waiting et un reason : answered, cancelled, expired, closed, not_actionable, not_delivered ou contact_unavailable.
Un second rappel dans les 24 heures renvoie 429 avec code case_request_reminder_too_soon, un horodatage retry_at et un en-tête Retry-After.
Tant qu’une résolution est en attente d’approbation, un rappel renvoie 400.
L’endpoint client est GET ou POST /v3/case-requests/{request_uuid}/, avec son en-tête X-Case-Request-Token propre à la requête.
Le lien de réponse transporte cet identifiant d’accès dans son fragment ; la page supprime le fragment à l’ouverture.
Le jeton ne donne accès qu’à cette requête.