Différences

Ci-dessous, les différences entre deux révisions de la page.

--- guide_callbacks [2025/05/14 18:14] – [CALLBACK FINALE] klafont
+++ guide_callbacks [2025/10/08 10:56] (Version actuelle) – [🔁 Callbacks – À quoi servent-ils ?] admin
@@ Ligne 1: / Ligne 1: @@
+[[:guide_callbacks|Français]] | [[:en:guide_callbacks|English]]
+----
 ====== INTRODUCTION AUX CALLBACKS ======
-==== LES CALLBACKS, DE QUOI S’AGIT-IL  ? ====
+==== 🔁 Callbacks – À quoi servent-ils ? ====
-Lors de la création d'un dossier, il est essentiel de renseigner le champ **"callback_url"**. Cette URL de callback est appelée en mode POST par ID360, incluant un payload contenant plusieurs informations.
+Lors de la création d’un dossier, il est indispensable de renseigner un ou plusieurs **callback_endpoints**, c’est-à-dire des URL(s) sur lesquelles ID360 enverra automatiquement des notifications (en HTTP POST) tout au long du processus d’identification.
+Chaque callback_endpoint recevra un **payload** contenant des informations liées au dossier, notamment son statut et les étapes franchies par l’utilisateur.
+=== 📌 Que peut-on configurer ? ===
+Vous avez la possibilité de renseigner **une ou plusieurs URLs de callback**. Pour chaque callback, vous pouvez définir le niveau de notification souhaité :
+  * **Callback finale uniquement** : vous recevez une seule notification à la fin du processus, indiquant que l’identification est terminée, avec les informations associées.
+  * **Callbacks intermédiaires + finale** : vous êtes notifiés à chaque étape clé du parcours utilisateur (début, upload, validation des documents, etc.), en plus de la notification finale.
+=== ⚠️ Attention à l’ordre d’arrivée des callbacks ===
+Il est important de noter que dans certains cas, **des callbacks intermédiaires peuvent arriver après la callback finale**.
+Cela peut se produire si l’envoi initial d’une callback a échoué (par exemple si votre serveur était temporairement indisponible) : ID360 effectuera alors des **re-tentatives automatiques (retries)** pour garantir la bonne réception.
-**Les callbacks intermédiaires** vous permettront d’être notifié pour chaque étape accomplie par l'utilisateur dans le cadre de son processus d'identification et vous fourniront des informations sur le bon déroulement du processus.
+Ces retries peuvent provoquer un **désalignement temporel dans l’ordre des messages reçus**.
-Enfin, **la callback finale**, émise à la fin du processus d'identification, vous informera de la fin du processus d’identification et vous donnera des informations sur cette dernière.
+  * → Il est donc fortement recommandé de **vous baser sur le contenu du payload** plutôt que sur l’ordre d’arrivée des notifications.
-Vous avez la possibilité de choisir de recevoir des callbacks seulement en fonction du statut du dossier, ce sont les **callback_endpoints**.
 ==== LA CONSTRUCTION DU PAYLOAD ====
@@ Ligne 37: / Ligne 54: @@
 La valeur **done = 1** signifie que seule l’étape ProfileDataStep (qui était de pousser le nom de famille par API) a été finalisée.
-Le champ **enrollment_step** fournit des informations détaillées sur l’étape, notamment le résultat du contrôle, le type de vérification effectuée, ainsi que la liste des documents concernés.
+Le champ **enrollment_step** fournit des informations détaillées sur l’étape, notamment le résultat du contrôle, le type de vérification effectuée, ainsi que la liste des documents concernés. Le statut présent dans enrollment_step peut être OK, KO, FAILED, USER_PROCESSING, SYS_PROCESSING.
 **Le type présent dans la variable enrollment_step est une information interne, à ce titre, il ne doit pas être utilisé ou exploité.**
@@ Ligne 46: / Ligne 63: @@
 ^ ‘enrollment_step’ > ‘name’ ^ Document(s) ^ Contrôle / Remarque ^
 | id_document | Pièce d’identité | La pièce d’identité a bien été reçue et lue par ID360 |
-| id_document_mandat | Pièce d’identité | La pièce d’identité de la personne présente dans le KBIS a bien été reçue et lue par ID360 |
+| id_document_mandate | Pièce d’identité | La pièce d’identité de la personne présente dans le KBIS a bien été reçue et lue par ID360 |
 | fake_photo_id| Pièce d’identité | La photo présente sur la pièce d’identité est conforme |
 | phone_detection | Pièce d’identité | La détection d’attaque par présentation s’est bien déroulée |
+| image_forensics | Pièce d’identité | La détection de la monochromie s’est bien déroulée |
 === Moyens d’identification électronique ===
@@ Ligne 94: / Ligne 112: @@
 Dans le steps_status la valeur « done » sera égale à la valeur « total ».
+\\
-----
+\\
+\\
 Dans le cadre de cette callback, vous devez renvoyer un code 2XX (par exemple 204) dans un délai inférieur à 10 secondes.
 Si cette réponse n’est pas reçue, jusqu’à 6 nouvelles tentatives (retries) seront effectuées selon le planning suivant :
-^ Tentative ^ Secondes ^ Minutes ^
+^ Tentative ^ Secondes ^ Minutes ^ Minutes cumulées ^
-| 1         | 10       | 0,17     |
+| 1         | 10       | 0,17     | 0,17     |
-| 2         | 80       | 1,33     |
+| 2         | 80       | 1,33     | 1,50     |
-| 3         | 270      | 4,50     |
+| 3         | 270      | 4,50     | 6,00     |
-| 4         | 640      | 10,67    |
+| 4         | 640      | 10,67    | 16,67    |
-| 5         | 1250     | 20,83    |
+| 5         | 1250     | 20,83    | 37,50    |
-| 6         | 2160     | 36,00    |
+| 6         | 2160     | 36,00    | 73,50    |
-| 7         | 3430     | 57,17    |
+| 7         | 3430     | 57,17    | 130,67   |
 Ces intervalles sont calculés selon la formule : //
@@ Ligne 127: / Ligne 145: @@
     "headers": [
       {
-        "name": "Authorization: Bearer abc123"
+         "name": "Authorization", value: "Bearer abc123"
       }
     ]