Intégration
Faites entrer le verdict dans votre CRM avant l'appel, puis gardez votre file à jour grâce aux événements et aux re-vérifications.
API : Le verdict rejoint votre CRM avant l'appel.
Testez ponctuellement un jeton dans l'espace acheteur, puis branchez la même logique à l'arrivée de vos flux. Chaque clé API utilise le niveau de vérification de votre choix, ou celui défini par défaut sur votre compte.
- 1
Identifiez votre entreprise
Votre SIRET est vérifié auprès du répertoire officiel. Le SIREN associé permet ensuite de contrôler que la preuve autorise bien votre entreprise à contacter ce lead.
- 2
Créez une clé par environnement
Production, staging ou équipe métier : attribuez à chaque clé son niveau de vérification et, si besoin, une date d'expiration.
- 3
Transmettez le jeton et le contact
Envoyez le jeton avec l'e-mail et/ou le téléphone reçu. CertiLead vérifie que la preuve correspond bien au contact que vous vous apprêtez à appeler.
- 4
Recevez le verdict et les changements de statut
Obtenez une décision immédiate à l'entrée du lead, puis recevez les retraits et révocations par webhook ou interrogez-les via l'API.
Maintenir le CRM à jour
Le verdict entre par l'API. Ses changements arrivent sans attendre le prochain import.
- Webhook signé pour recevoir les retraits et révocations en temps réel
- Endpoint de rattrapage pour rejouer les événements non reçus par votre SI
client_refconservé pour rattacher chaque réponse à votre fiche CRM
Trois appels, et c'est tout.
Une intégration complète tient en trois points de contact. Le reste (le niveau de contrôle, les règles de routage et la facturation), se règle dans votre espace, sans une ligne de code de plus.
-
À l'entrée du lead
Vous demandez le verdict
Une requête, avec le jeton et le contact que vous détenez déjà. La réponse arrive avant que le lead n'entre en file d'appel.
Envoyez bien l’e-mail ou le téléphone : sans eux, la réponse porte
identity_checked: false, le rattachement au contact n’a pas été contrôlé.POST /api/v1/verifications -
Pendant la vie du lead
Vous êtes prévenu des changements
Un retrait ou une révocation part vers l'URL signée que vous déclarez. Si votre SI n'expose pas d'URL publique, interrogez le flux vous-même : le curseur reprend à la dernière livraison reçue, sans doublon ni oubli.
Push · nous appelons chez vous
POST https://votre-si/hooks/certileadPull · vous nous appelez
GET /api/v1/events?since= -
En cas de contestation
Vous sortez la preuve
L'attestation et le dossier de preuve se régénèrent à la demande depuis la vérification que vous avez payée, quel que soit le niveau. Vous n'accédez qu'à vos propres contrôles.
Le document n’est jamais stocké : il est reconstruit à chaque demande depuis la preuve scellée, qui elle ne bouge plus. Rien à archiver de votre côté.
GET /api/v1/verifications/:id/proof.pdf
Où ça se branche dans votre SI.
Quelle que soit la porte par laquelle vos leads entrent, ils passent par le même contrôle avant d'atteindre la file d'appel. Vous n'avez qu'un point à instrumenter.
Le cœur de l'intégration
La requête, en vrai.
Vous envoyez le jeton et le contact ; vous recevez un verdict exploitable par vos règles métier. Rien à installer : une requête HTTP, dans le langage que vous utilisez déjà.
Requête
POST /api/v1/verificationsX-API-Key: clk_votre_cleIdempotency-Key: crm:91042:call:550e8400-e29b-41d4-a716-446655440000Content-Type: application/json{ "token": "CL-26-QNOMTRPNZA5G", "level": 2, "identity": { "phone": "+33612345678" }, "client_ref": "CRM-91042", "context": { "purpose": "pre_call" }}
Réponse 200 · extrait
{ "ok": true, "status": "ok", "level": 2, "verification_status": { "code": "verified", "exploitable": true }, "identity_checked": true, "replay": { "billed": true, "remaining": 9 }}
Ce que vous n'avez pas à faire.
-
Aucun SDK à installerUne requête HTTP standard, dans le langage et le framework que vous utilisez déjà.
-
Aucun changement de CRM ni de dialerLe verdict est une donnée de plus sur la fiche. Vos outils et vos files restent les vôtres.
-
Aucune migration de donnéesVous envoyez le jeton et le contact reçus avec le lead (téléphone et/ou email). Rien à exporter, rien à recopier.
-
Aucun webhook obligatoireSi votre SI n'expose pas d'URL publique, interrogez l'endpoint de rattrapage à votre rythme.
Quatre points à régler une bonne fois.
-
01
Une clé par environnement
Commencez avec une clé de test, puis créez la clé de production quand vos règles de routage sont posées. Chaque clé porte son propre niveau de contrôle : vous ne risquez pas de vérifier en niveau 3 depuis un script de recette.
-
02
Une clé d'idempotence par tentative
Rejouer une requête avec la même
Idempotency-Keyrenvoie le même résultat au lieu d'ouvrir un second contrôle. C'est votre filet quand un lot est relancé ou qu'un message est traité deux fois. -
03
Une conduite à tenir si la réponse tarde
Fixez un délai d'attente et décidez d'avance ce qui se passe ensuite : la plupart des équipes mettent le lead en attente plutôt que de l'appeler sans verdict, puis rejouent la requête avec la même clé d'idempotence.
-
04
Votre référence interne dans chaque appel
Transmettez votre identifiant de fiche en
client_refet journalisez-le de votre côté : c'est ce qui vous permettra de rapprocher un contrôle, un événement de retrait et une ligne de facturation sans enquête.
Prouvez votre diligence, appel après appel.
Commencez dans l'interface, puis automatisez la vérification avec une clé dédiée à chaque environnement.
