reference.
Seul
/extract appelle le modèle de vision, donc seul /extract est décompté. Le quota est contrôlé avant la lecture du moindre fichier.
Le parcours principal
Ce que vous transmettez d’un appel au suivant :/assess prend le même corps que /verify et exécute d’abord la même vérification. Si vous voulez les deux réponses, appelez uniquement /assess : sa clé verification contient le verdict complet.
Pourquoi renvoyer les entrées
/verify ne lit pas de fichiers. Il contrôle les entrées documents[] que vous envoyez, donc il a besoin de ce que /extract a vu : le type de document, les champs, les dates du fichier et le step_key. Sans le step_key, un même document pourrait passer le contrôle de type à /extract et l’échouer à /verify. L’API place le step_key sur chaque entrée pour cette raison.
Si vous modifiez une entrée, vous vérifiez votre modification, pas le document.
Le parcours eID
Le fournisseur n’envoie aucun rappel. Vous interrogez l’API, et Sahl envoie le webhookkyc.eid_completed la première fois qu’une interrogation voit l’état final. Les détails sont dans Contrôle eID. Dans cette version, l’eID est réservé aux clients canadiens, donc la requête d’exemple utilise country=CA ; tous les autres appels de cette page acceptent n’importe quel pays, par exemple MA.
Cycle de vie d’un dossier
Un dossier existe une fois par espace de travail, environnement etreference. Chaque appel avec cette référence le met à jour.
Une nouvelle vérification n’écrase jamais un statut fixé par une personne : approved et refused restent.
Choisir les appels
L’API n’a ni clé d’idempotence ni endpoint par lot. Envoyer deux fois le même appel lit les fichiers deux fois, compte deux lectures et classe un second jeu de documents sur le dossier. Voir Erreurs et nouvelles tentatives.