Dawap relie Aircall à votre CRM, helpdesk, application ou reporting quand un appel terminé ne suffit pas à créer une activité juste. Le connecteur conserve le call ID, le numéro réellement composé, la ligne Aircall, les agents, les transferts, les tags et les événements reçus ; il résout ensuite le bon contact, protège l’accès aux enregistrements et confirme l’effet obtenu dans le système métier.
Réponse immédiate
Dawap construit le middleware entre Aircall et votre logiciel. Les webhooks alimentent une file par call ID, le worker rapproche raw_digits, ligne, agents, transferts, tags et commentaires, puis relit le CRM avant de créer ou mettre à jour une activité. L’historique REST sert au rattrapage ; une URL signée d’enregistrement ou un contact Aircall ne sont jamais assimilés à une identité métier fiable.
Aircall call reconciliation desk · dossier fictif
Cette maquette ne se connecte à aucun compte. Le numéro, la ligne, les personnes, le call ID et les événements servent uniquement à montrer le niveau de contrôle attendu.
Deux comptes actifs partagent le numéro. Ni le score ni l’ordre des résultats ne peuvent choisir l’owner.
Le dossier garde raw_digits et la ligne, puis passe par le moteur de candidats.
L’activité existante reçoit une qualification si aucune décision humaine plus récente ne s’y oppose.
La clé externe permet de reconnaître l’effet déjà obtenu et d’éviter une seconde tâche.
Les deux systèmes gardent leur identité et le lien qui les rapproche.
L’absence dans Aircall ouvre une recherche ; elle ne supprime pas le contexte métier.
Les événements successifs enrichissent un même dossier jusqu’au verdict attendu.
L’accès technique ne décide ni de la finalité ni de la durée de conservation.
Quand l’appel est “done”
Plusieurs événements décrivent un même appel. Le contact Aircall peut être nul, un numéro peut correspondre à plusieurs fiches et un tag peut arriver après la fin. Sans réconciliation, le système cible transforme une chronologie utile en doublons ou en certitudes inventées.
raw_digits sert de clé de recherche, pas de preuve d’identité. Un numéro partagé ou réattribué ouvre une décision ; il ne justifie pas une association silencieuse.
call.created, call.answered, call.ended, call.tagged et call.commented décrivent un même call ID. Le worker fait un upsert et conserve l’ordre observé.
Recording et voicemail sont des URLs signées avec une durée de vie. Droit d’accès, téléchargement éventuel, conservation et suppression doivent être décidés avant le stockage.
Contrats Aircall
Aircall expose appels, contacts, utilisateurs, numéros et événements. Le projet attribue encore chaque identité, transition et effet CRM.
Basic Authentication convient au raccord privé de vos propres outils ; OAuth est prévu pour une application publique qui agit pour plusieurs comptes autorisés.
Tous les événements d’un appel rejoignent le même dossier par call.id. La clé CRM reste distincte et les deux identifiants sont conservés.
raw_digits initie la recherche. Le champ contact peut être nul ; plusieurs candidats ou une fusion CRM exigent une règle ou une revue humaine.
Création, sonnerie, réponse, transfert, fin, tag et commentaire portent occurrence et réception. Une arrivée tardive enrichit l’activité sans la dupliquer.
Recording, voicemail, transcription éventuelle, numéros et commentaires suivent des droits, une finalité, une rétention et des logs expurgés.
Webhooks pour le temps réel, REST paginé pour l’historique et le contrôle : rate limits, backoff, checkpoints et replay restent visibles au support.
Méthode call-first
Dawap réunit métier, sales, support, sécurité et IT autour d’un appel qui a déjà créé un doute. On nomme la ligne, le numéro, les candidats, l’owner, la qualification et l’action attendue. Le worker ingère d’abord en lecture seule, rejoue les cinq ruptures, puis ouvre une seule écriture idempotente avant toute extension.
Une activité CRM reliée au call ID, au bon contact et à la chronologie réellement observée.
Des appels manqués, transferts, tags tardifs et commentaires traités sans nouvelles activités parasites.
Des enregistrements accessibles uniquement dans le périmètre et pendant la durée décidés.
Un support capable de comparer Aircall et le système cible puis de reprendre un seul dossier.
Premier lot Aircall
On choisit une ligne Aircall, un type d’appel et une activité cible. La première passe inventorie accès, événements et champs en lecture seule. La création CRM ne s’ouvre qu’après validation du matching, de l’upsert et des cinq contre-tests.
Sorties attendues
Registre Aircall–CRM avec call ID, raw_digits, line/number ID, user ID, contact candidates et activité cible.
Choix Basic Auth ou OAuth, inventaire des comptes, credentials, webhooks, propriétaires et droits sur les enregistrements.
Machine d’état pour created, answered, transferred, hungup, ended, tagged, commented et voicemail_left.
Cinq contre-tests : contact nul, numéro partagé, événement rejoué, tag tardif et recording expiré ou interdit.
Upsert CRM avec clé externe, règles de merge, owner, statut, note, consentement et reçu de l’effet obtenu.
Backfill paginé, rapprochement périodique, limites, alertes, quarantaine, replay ciblé et runbook support.
Recette Aircall
Ces scénarios sont illustratifs et doivent être rejoués sur votre compte, vos lignes, vos règles de matching et votre CRM. Ils ne constituent pas des résultats clients ni une intégration Aircall déjà livrée.
Frontières de responsabilité
Aircall porte l’appel. Le CRM, le support et l’architecture transverse conservent leurs propres objets et responsabilités.
Avis & exigence projet
Token, event, call ID et payload utile sont conservés puis acquittés rapidement.
Numéro, ligne, candidats, owner et action cible sont arbitrés sans association silencieuse.
Aircall et CRM sont relus ; doublons, conflits et assets vocaux gardent une conduite à tenir.
Pour relier Shopetic à Origami, Dawap a réparti catalogue, client, panier multivendeur, livraison, paiement et commandes dans 24 adaptateurs et 21 mappers. Soixante-cinq opérations alimentent les parcours, tandis que 14 mutations sensibles conservent leur requête, leur statut et leur réponse pour faciliter le diagnostic.
Dawap a transformé la relation client de 1UP Distribution en portail B2B multi-compte : onboarding, catalogue contextualisé, tarifs issus d’Odoo, disponibilité vendable, paniers réservés, commandes, factures, avoirs et support. Une expérience autonome qui conserve les règles commerciales, les droits et les preuves nécessaires au run.
L’API Aircall relie appels, contacts et journalisation CRM avec des événements dont l’ordre peut varier entre sonnerie, réponse et clôture. Pour traiter ce point sans raccourci, il faut rapprocher numéros, utilisateurs et dossiers, afin de produire une timeline utile sans créer plusieurs activités pour le même appel ni exposer des données inutiles.
Un webhook signé doit prouver son origine, l’intégrité du corps et la fraîcheur de la requête avant tout effet métier. Une mise en œuvre rigoureuse consiste à vérifier signature, horodatage et identifiant, puis à bloquer le rejeu, afin qu’un attaquant ou une nouvelle tentative ne déclenche pas deux paiements ou mises à jour.
Un webhook tardif ne doit ni ramener une commande en arrière ni être ignoré par réflexe. La stratégie compare version, temps métier, préconditions et état courant, puis choisit application, attente, isolation ou réconciliation. Elle traite aussi événements manquants, concurrence, rejeu et preuve de la projection reconstruite.
Audit trail API garde la preuve utile quand le support, la conformité et le run doivent reconstituer une action sans fouiller tout le système. La trace doit montrer qui a fait quoi, quand, sur quel endpoint et avec quel contexte, puis rester exploitable après incident. Il reste utile quand un incident tombe après coup.
Questions d’achat
Les réponses à clarifier avant de relier appels, contacts et événements Aircall à votre CRM, helpdesk ou reporting.
Quand Aircall doit alimenter votre CRM, helpdesk, application ou reporting avec des règles d’identité, de chronologie, de droits, d’idempotence, d’observabilité et de reprise propres à votre métier.
Aircall destine Basic Authentication aux intégrations privées de vos propres outils. OAuth est adapté aux applications publiques qui accèdent aux comptes de plusieurs clients après autorisation. Le choix dépend donc du produit, pas d’une préférence technique.
Le middleware utilise call.id comme clé Aircall stable, stocke chaque événement dans une inbox, puis fait un upsert sur une clé externe côté CRM. Après un timeout, il relit l’activité avant toute nouvelle écriture.
Non. Aircall précise qu’il peut être nul, notamment pour des contacts venant d’un CRM externe. raw_digits sert de clé de recherche, mais un numéro partagé ou réattribué exige encore une règle de contexte ou une décision humaine.
Un appel manqué se lit avec status done et missed_call_reason ; il n’existe pas un type missed unique. La durée inclut la sonnerie, tandis que le temps parlé se calcule avec answered_at et ended_at lorsque answered_at existe.
Une ligne, un type d’appel et une activité CRM, avec un appel témoin et cinq contre-tests. Contacts, reporting étendu, autres lignes et automatisations ne rejoignent le lot qu’après une reprise réussie par le support.
Aircall Public API · appels et CRM
Dawap cadre les accès, identités, événements, écritures, assets vocaux et reprises avant d’ouvrir le flux à toutes vos lignes.
Cadrer mon flux Aircall
