Intégration & API

אינטגרציה ו-API

Utiliser les Webhooks Kavkom

Un webhook permet à une application d’envoyer automatiquement des informations à une autre lorsqu’un événement se produit.

Avec Kavkom, les événements téléphoniques que vous sélectionnez sont transmis vers l’URL de votre choix à l’aide de requêtes HTTP POST. Le format du corps dépend de l’événement : le POST de transcription est notamment envoyé en application/x-www-form-urlencoded, avec une valeur contenant du JSON.

Vous pouvez notamment recevoir des informations :

  • pendant un appel entrant ;
  • pendant un appel sortant ;
  • après la fin d’un appel grâce au CDR (Call Detail Record).
Principe. Votre application n’a pas besoin d’interroger régulièrement Kavkom pour rechercher de nouveaux événements. Kavkom envoie automatiquement les informations sélectionnées vers votre endpoint.

Exemples d’utilisation

📞

Activités d’appels

Transmettez les informations relatives aux appels entrants, sortants ou terminés vers votre CRM ou votre application métier.

🔴

Suivi d’un appel en direct

Recevez les changements d’état d’un appel pendant son déroulement et utilisez-les dans vos interfaces ou automatisations.

📵

Appels non aboutis

Exploitez le résultat final d’un appel pour créer une tâche, générer une alerte ou déclencher une relance dans un outil externe.

🎙️

Enregistrements d’appels

Lorsqu’un enregistrement est disponible, son URL peut être transmise dans le CDR à l’aide du champ recording_url.

📝

Transcriptions d’appels

Lorsqu’une transcription est disponible, recevez son texte dans un POST distinct et associez-le à l’appel grâce à l’identifiant du CDR.

📊

Statistiques et reporting

Envoyez les données des appels terminés vers vos outils d’analyse, vos tableaux de bord ou vos solutions de Business Intelligence.

⚙️

Automatisations métiers

Déclenchez vos propres workflows à partir des événements et données d’appels reçus depuis Kavkom.

Enregistrements. Le webhook ne transmet pas le fichier audio de l’enregistrement. Il transmet uniquement son URL lorsqu’elle est disponible.

Configurer un webhook Kavkom

Avant de commencer, assurez-vous de disposer d’un endpoint capable :

  • de recevoir des requêtes HTTP POST ;
  • de traiter le contenu selon son Content-Type, notamment les données JSON lorsqu’elles sont envoyées sous ce format et le formulaire application/x-www-form-urlencoded pour la transcription ;
  • de retourner une réponse HTTP.

Connectez-vous à Kavkom avec un compte disposant des autorisations nécessaires, puis rendez-vous dans :

Réglages avancés → Intégrations → Webhook → Installer

La fenêtre de configuration regroupe les six zones présentées ci-dessous.

Vue d'ensemble de la fenêtre de configuration du Webhook Kavkom avec repères numérotés
1Endpoint et test de connexion.
2Headers HTTP personnalisés.
3Variables personnalisées.
4Choix des types d’appels à pousser.
5Mapping des appels en direct.
6Mapping des CDR après la fin de l’appel.

1. Indiquer l’Endpoint

Dans le champ Endpoint, saisissez l’URL vers laquelle Kavkom doit envoyer les requêtes.

Configuration de l'endpoint du Webhook Kavkom et bouton Test
1Saisissez l’URL de réception de votre webhook.
2Test envoie une requête vide afin de vérifier que le receveur répond.
https://example.com/webhooks/kavkom

Tester l’Endpoint

Après avoir renseigné l’adresse, cliquez sur le bouton Test.

Kavkom envoie alors une requête vide vers l’endpoint et attend une réponse du serveur destinataire.

À quoi sert le test ?
Il permet de vérifier que le serveur destinataire est joignable avant d’activer l’envoi des événements téléphoniques.
Le test ne simule pas un appel réel et ne contient pas les données d’un appel.

2. Configurer les Headers

La section Headers permet d’ajouter des informations aux en-têtes HTTP envoyés avec les requêtes.

Configuration des headers du Webhook Kavkom
1Key : nom de l’en-tête HTTP.
2Value : valeur transmise avec l’en-tête.
3Ajouter : ajoute une nouvelle paire Key / Value.

Chaque header est constitué d’une paire Key / Value. Ils peuvent notamment servir à transmettre les informations nécessaires à l’authentification de votre endpoint.

Key: Authorization
Value: Bearer votre_token
Sécurité. Évitez de placer des informations sensibles directement dans l’URL. Utilisez de préférence les headers pour transmettre vos informations d’authentification.

3. Ajouter des Variables

La section Variables permet d’ajouter des paramètres personnalisés sous forme de paires Key / Value.

Configuration des variables du Webhook Kavkom
1Key : nom de la variable personnalisée.
2Value : valeur associée.
3Ajouter : ajoute une nouvelle variable.

Ces variables peuvent servir à transmettre des informations complémentaires propres à votre intégration, par exemple un identifiant d’environnement, de compte ou de traitement.

4. Choisir les appels à transmettre

Dans la section What calls should be pushed?, sélectionnez les catégories d’événements que Kavkom doit envoyer vers votre endpoint.

Choix des appels à transmettre par le Webhook Kavkom
1Entrants : événements des appels entrants en direct.
2Sortants : événements des appels sortants en direct.
3CDR : données envoyées après la fin de l’appel.

Vous pouvez activer plusieurs catégories simultanément.

5. Configurer le mapping des données

Kavkom propose deux mappings indépendants :

  • Mapping for life calls pour les appels en direct ;
  • Mapping for CDR pour les appels terminés.
Si aucun mapping n’est configuré : Kavkom transmet l’ensemble des données disponibles pour le type d’événement concerné.

Si vous configurez un mapping, vous pouvez associer une clé de votre choix au champ Kavkom attendu par votre application.

Mapping for life calls

Mapping des appels en direct dans le Webhook Kavkom
1Définissez la clé de sortie attendue par votre système.
2Sélectionnez le champ Kavkom à associer.
3Ajouter permet de créer une correspondance supplémentaire.

Ce mapping concerne les événements des appels entrants et sortants en direct.

Mapping for CDR

Mapping des CDR dans le Webhook Kavkom
1Définissez la clé de sortie attendue par votre système.
2Sélectionnez le champ CDR Kavkom à associer.
3Ajouter permet de créer une correspondance supplémentaire.

Ce mapping concerne les données finales envoyées après la fin de l’appel.

Données disponibles pour les appels en direct

ChampDescription
domain_uuidIdentifiant du domaine Kavkom.
callIdIdentifiant de l’appel en cours.
numberNuméro associé à l’événement d’appel.
extensionExtension concernée par l’appel.
directionDirection de l’appel.
stateÉtat de l’appel au moment où l’événement est envoyé.

À quoi sert le champ state ?

Le champ state permet à votre application de suivre l’évolution d’un appel et d’adapter son traitement selon les événements reçus.

Important. Les événements en direct décrivent l’état d’un appel. Ils ne permettent pas de savoir si un utilisateur Kavkom est actuellement connecté ou déconnecté et ne constituent pas un statut global de disponibilité de l’utilisateur.

Données disponibles pour les appels terminés

Le Mapping for CDR permet d’exploiter les informations disponibles après la fin d’un appel.

ChampDescription
xml_cdr_uuidIdentifiant unique du CDR.
domain_nameDomaine associé à l’appel.
directionDirection de l’appel.
statusStatut final de l’appel.
durationDurée totale de l’appel.
billsecDurée de communication comptabilisée.
outside_numberNuméro externe associé à l’appel.
destination_numberNuméro de destination.
referenced_didDID référencé pour l’appel.
referenced_extensionExtension référencée pour l’appel.
caller_id_numberNuméro utilisé comme identifiant de l’appelant.
caller_destinationDestination associée à l’appel.
start_epochHeure de début au format Epoch.
start_stampDate et heure de début.
end_epochHeure de fin au format Epoch.
end_stampDate et heure de fin.
answer_stampDate et heure de réponse.
answer_epochHeure de réponse au format Epoch.
recording_urlURL de l’enregistrement lorsque celui-ci est disponible.
Selon le type d’appel et son déroulement, certaines données peuvent ne pas être renseignées.

Recevoir la transcription d’un appel

Lorsqu’une transcription est disponible, Kavkom peut envoyer le texte de l’appel dans une requête HTTP POST distincte de celle du CDR. Cette requête contient deux paramètres principaux : cdr_uuid et transcription_data.

Format du POST de transcription. L’en-tête HTTP est Content-Type: application/x-www-form-urlencoded. Le corps de la requête n’est pas un objet JSON brut : il contient des paramètres de formulaire encodés dans l’URL, dont une valeur renferme du JSON.

Structure du corps HTTP

Voici un exemple simplifié de requête, avec un identifiant et une transcription fictifs :

POST /votre-endpoint HTTP/1.1
Content-Type: application/x-www-form-urlencoded

cdr_uuid=927ec63d-1fa1-4b83-a548-907d612b5842&transcription_data=%5B%7B%22transcript%22%3A%22Bonjour%2C+je+souhaite+une+information.%22%7D%5D
ÉlémentDescription
cdr_uuidIdentifiant du CDR associé à l’appel. Sa valeur correspond à celle de xml_cdr_uuid dans le POST du CDR.
transcription_dataParamètre de formulaire contenant une chaîne JSON encodée, qui représente un tableau d’objets de transcription.
transcriptPropriété présente dans un objet du tableau transcription_data ; sa valeur contient le texte transcrit.
&Sépare les paramètres du formulaire dans le corps HTTP.
%5B, %7B, %22Exemples de caractères encodés : [, { et les guillemets ".
+Représente un espace dans une valeur de formulaire encodée.

Comment interpréter les données reçues ?

  1. Lire le corps comme un formulaire application/x-www-form-urlencoded pour retrouver les valeurs de cdr_uuid et transcription_data.
  2. Décoder la valeur de transcription_data (son encodage de formulaire, puis le JSON qu’elle contient) afin d’obtenir un tableau d’objets.
  3. Lire la propriété transcript des objets de ce tableau pour accéder au texte de transcription.
  4. Rapprocher la valeur de cdr_uuid avec xml_cdr_uuid pour associer la transcription au bon appel.

Après décodage, les mêmes données peuvent être représentées ainsi dans votre application. Ce bloc est une représentation logique ; il ne correspond pas au corps HTTP brut envoyé par Kavkom :

{
  "cdr_uuid": "927ec63d-1fa1-4b83-a548-907d612b5842",
  "transcription_data": [
    {
      "transcript": "Bonjour, je souhaite une information."
    }
  ]
}
Caractères accentués. Le texte peut contenir des séquences JSON comme \u00e9. Elles deviennent des caractères lisibles (ici é) après l’analyse du JSON. Le décodage du formulaire seul ne suffit pas pour exploiter directement cette valeur structurée.

Associer la transcription au CDR

Deux noms de champs différents désignent ici le même identifiant d’appel :

POST du CDR
xml_cdr_uuid
POST de transcription
cdr_uuid
Clé de rapprochement. La valeur de cdr_uuid reçue avec la transcription correspond à la valeur de xml_cdr_uuid reçue avec le CDR. Votre application peut ainsi rattacher la transcription à la bonne fiche d’appel ou activité CRM.

Exemple de traitement en JavaScript

Une fois le corps HTTP brut récupéré par votre serveur, vous pouvez le décoder comme suit :

// rawBody : contenu brut de la requête HTTP POST
const params = new URLSearchParams(rawBody);
const cdrUuid = params.get("cdr_uuid");
const transcription = JSON.parse(params.get("transcription_data") || "[]");

// Chaque élément peut contenir une propriété "transcript".
const textes = transcription.map(item => item.transcript);

// Rattacher l'ensemble à un CDR dont xml_cdr_uuid === cdrUuid.

Le décodage d’un formulaire est généralement effectué par le framework backend ; dans ce cas, analysez directement la chaîne reçue dans le paramètre transcription_data comme du JSON, sans la décoder deux fois.

Bon à savoir. Le CDR et la transcription sont transmis dans des POST distincts. Pour le rapprochement, utilisez l’identifiant plutôt que de supposer un ordre ou un délai fixe de réception. La capture d’écran de configuration présente les options des appels en direct et des CDR ; elle ne documente pas de paramètre spécifique d’activation de la transcription.

Une transcription peut contenir des informations confidentielles ou personnelles. Protégez l’accès à ces données et appliquez les règles de conservation et d’accès adaptées.

Enregistrement d’appel

Lorsqu’un appel a été enregistré et qu’une URL est disponible, elle peut être transmise à votre application dans le champ :

recording_url
Le fichier audio n’est pas envoyé dans le webhook.
Kavkom transmet uniquement l’URL de l’enregistrement.

Votre application peut ensuite décider comment exploiter cette URL : l’associer à une activité CRM, l’utiliser dans une application métier, déclencher un traitement externe ou l’intégrer à votre propre processus d’archivage.

Appels en direct et CDR : quelle différence ?

Appels en directCDR
Envoyés pendant le déroulement de l’appel.Envoyé après la fin de l’appel.
Décrivent l’état courant de l’appel.Contient les informations finales disponibles.
Permettent de suivre l’évolution de l’appel.Permet d’exploiter le résultat de l’appel.
callId, extension, direction, state…status, duration, billsec, horodatages, recording_url…
Les appels en direct et les CDR peuvent être activés simultanément sur le même webhook.

Exemple d’utilisation avec un CRM

  1. Un appel entrant est reçu sur Kavkom.
  2. Kavkom envoie un événement vers votre endpoint.
  3. Votre application récupère le numéro et les informations disponibles.
  4. Le CRM peut rechercher le contact correspondant et créer ou mettre à jour une activité.
  5. Les événements suivants permettent de suivre l’évolution de l’appel.
  6. Lorsque l’appel se termine, Kavkom envoie le CDR.
  7. Votre application peut enregistrer le statut, la durée et les autres informations finales disponibles.
  8. Si un enregistrement existe, son URL peut être associée à l’activité.
  9. Lorsqu’une transcription est reçue, le CRM peut la rattacher à cette même activité grâce à cdr_uuid et xml_cdr_uuid.

Bonnes pratiques

Utilisez HTTPS

Utilisez de préférence un endpoint HTTPS pour sécuriser les échanges entre Kavkom et votre serveur.

Authentifiez votre endpoint

Utilisez les headers pour transmettre les informations nécessaires à l’authentification.

Validez les données reçues

Vérifiez les valeurs reçues avant de les transmettre à vos systèmes métiers.

Prévoyez les champs vides

Certaines informations peuvent ne pas être renseignées selon le scénario d’appel.

Conservez les identifiants

Les identifiants d’appels facilitent la corrélation des événements et les diagnostics.

Répondez rapidement

Votre serveur doit retourner une réponse HTTP lorsque le webhook a correctement été reçu.

À retenir

Les webhooks Kavkom permettent de connecter les événements de votre téléphonie à vos applications externes sans avoir à interroger continuellement le système.

  • événements des appels entrants en direct ;
  • événements des appels sortants en direct ;
  • CDR des appels terminés ;
  • URL d’un enregistrement lorsqu’elle est disponible.
  • le texte de la transcription lorsqu’il est disponible, avec un identifiant permettant de le rapprocher du CDR.

Le mapping permet ensuite de sélectionner et d’adapter les données transmises aux besoins de votre CRM, de votre logiciel métier ou de votre application.

תוכן