Aller au contenu

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.

Interface pour commencer, API pour industrialiser

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.

Deux professionnels raccordent un verdict de vérification à une file CRM
L'API renvoie des champs structurés ; vos règles métier décident de la file suivante.

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_ref conservé pour rattacher chaque réponse à votre fiche CRM
L'étendue du travail

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.

  1. À 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
  2. 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 vousPOST https://votre-si/hooks/certilead

    Pull · vous nous appelezGET /api/v1/events?since=

  3. 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
Un seul endroit à modifier

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.

File d'attente

3 en attente de traitement

CertiLead

Appel
Écarté

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 ça n'exige pas

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.
Avant de basculer

Quatre points à régler une bonne fois.

  1. 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.

  2. 02

    Une clé d'idempotence par tentative

    Rejouer une requête avec la même Idempotency-Key renvoie 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.

  3. 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.

  4. 04

    Votre référence interne dans chaque appel

    Transmettez votre identifiant de fiche en client_ref et 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.