Intégration API Pipedrive sur mesure : quand y aller, et comment la construire

Une intégration sur mesure avec l'API Pipedrive n'est pas toujours la bonne réponse. Pour remonter les clients d'une boutique ou créer une activité quand une affaire change d'étape, une plateforme comme n8n ou les automatisations natives font le travail, et le font bien.

Le sur-mesure se justifie dans des cas précis, et il se construit d'une manière précise. Pipedrive a quelques particularités qui ne pardonnent pas à une intégration écrite comme on l'écrirait pour un autre CRM. Voici les deux : quand y aller, et comment la construire pour qu'elle tienne.

Chiffres relevés dans la documentation développeurs de Pipedrive le 4 octobre 2026.

Quand le sur-mesure se justifie

Une plateforme d'automatisation reste le bon point de départ. Je propose une intégration développée contre l'API quand l'un de ces quatre cas se présente.

1. 01

   Le volume. Une reprise de dizaines de milliers de lignes, une synchronisation continue de tout le fichier clients. Le quota de jetons devient alors la contrainte principale, et il faut maîtriser chaque appel.

2. 02

   Les deux sens. Pipedrive et un outil métier modifient les mêmes fiches. Il faut décider qui gagne en cas de conflit, et éviter que chaque mise à jour en déclenche une autre en retour.

3. 03

   La logique métier. Calculer un montant à partir de plusieurs sources, rattacher une affaire au bon compte selon vos règles. Au-delà d'une certaine taille, cette logique est plus lisible et plus testable dans du code.

4. 04

   L'outil sans connecteur. Un ERP, un logiciel métier, une base interne : rien d'existant ne le relie à Pipedrive, et il faut écrire les deux bouts.

Si aucun de ces cas ne vous concerne, commencez plus simple. Intégrer Pipedrive à Shopify en montre un exemple complet, méthode par méthode.

Les briques de l'API, et leurs pièges

Jeton personnel ou application OAuth

Il existe deux façons de s'authentifier.

Le jeton d'API est le plus simple. Il est lié à un utilisateur et à une entreprise, et donne accès à toutes les données de cet utilisateur. Un utilisateur n'en a qu'un seul actif à la fois, et s'il le régénère, toutes les intégrations qui l'utilisent cessent de fonctionner.

L'application OAuth 2.0 est la voie prévue pour les applications. Elle n'a pas besoin d'être publiée sur le Marketplace : Pipedrive propose des applications privées, installées par un lien direct non répertorié, sans validation. Elle a un avantage concret sur le jeton : sa limite de rafale est quatre fois plus élevée à offre égale.

La version 2, à préférer partout où elle existe

Pipedrive a publié une version 2 de son API, qu'il présente comme moins sujette aux changements cassants, plus rapide sur les gros volumes et moins coûteuse en jetons. Elle couvre aujourd'hui les affaires, les personnes, les organisations, les activités, les produits, les pipelines et leurs étapes, les champs et la recherche.

Tout le reste — les notes et les prospects, par exemple, absents de cette liste — passe encore par la version 1. Une intégration réelle mélange donc les deux, et c'est normal. Quand un point de la version 1 a son équivalent en version 2, Pipedrive annonce un délai de grâce d'au moins un an avant de le retirer.

Les deux versions diffèrent aussi dans la manière de parcourir une liste. La version 1 pagine par décalage (start, limit), la version 2 par curseur (cursor, limit), plus stable quand les données changent pendant le parcours. Dans les deux cas, 500 éléments par page au maximum.

Les champs personnalisés n'ont pas de nom

Un champ personnalisé n'est pas désigné par son libellé, mais par une clé de 40 caractères générée au hasard, du type dcf558aac1ae4e8c4f849ba5e668430d8df9be12. Cette clé diffère d'un compte Pipedrive à l'autre.

Deux conséquences pratiques :

• Rien ne se code en dur. La correspondance entre vos champs et ces clés vit dans une configuration, propre à chaque compte. Elle se trouve dans Company settings > Data fields (le menu « Copy API key » de chaque champ), ou se lit par l'API.
• Le format dépend du type de champ. Un champ monétaire, par exemple, s'accompagne d'une seconde clé suffixée _currency pour la devise. La documentation conseille de lire d'abord un objet existant pour voir le format attendu : c'est ce que je fais avant d'écrire la moindre ligne de mapping.

Le quota, en une phrase

Pipedrive ne compte pas les appels mais leur coût, sur un budget quotidien de jetons qui dépend de l'offre et du nombre de sièges. Une recherche coûte 40 jetons, une lecture simple 2 : une recherche vaut vingt lectures. Je détaille le calcul et ses conséquences sur la page Expert Pipedrive.

Ce qu'il faut en retenir pour la conception : une bonne intégration garde les identifiants Pipedrive de ce qu'elle a déjà créé, au lieu de les rechercher à chaque passage. S'y ajoute une limite de rafale sur deux secondes — de 20 requêtes en Lite à 120 en Ultimate pour un jeton d'API, et 10 requêtes toutes les deux secondes pour la recherche, quelle que soit l'offre.

Les webhooks : rapides, mais pas une source de vérité

Pour réagir à ce qui se passe dans Pipedrive, les webhooks évitent d'interroger l'API en boucle — le même raisonnement que pour les webhooks Shopify. Ils couvrent la création, la modification et la suppression de la plupart des objets : affaires, personnes, organisations, activités, prospects, notes, produits…

Leur atout : pour une modification, le message dit quels champs ont changé, avec leur valeur précédente. On sait ce qui a bougé sans relire la fiche.

Leurs limites, elles, imposent une architecture :

1. 01

   Dix secondes pour répondre. Au-delà, ou sur une erreur, Pipedrive réessaie trois fois — à 3, 30 puis 150 secondes. Un récepteur qui traite le message avant de répondre finit par dépasser ce délai.

2. 02

   Des messages perdus. Chaque échec à la première tentative fait monter un compteur. À dix, le webhook est suspendu trente minutes, et les événements de cette période sont perdus : rien n'est conservé.

3. 03

   Une suppression silencieuse. Sans aucune livraison réussie pendant trois jours de suite, le webhook est supprimé. Une intégration en panne un vendredi soir peut ne plus rien recevoir le lundi, sans erreur visible côté Pipedrive.

Un utilisateur peut créer jusqu'à 40 webhooks, protégés au besoin par une authentification HTTP de base.

L'architecture que je mets en place

Ces contraintes dessinent presque toujours la même structure.

Un récepteur qui répond tout de suite. Il vérifie l'authentification, met le message en file d'attente et répond en moins d'une seconde. Le traitement se fait ensuite, à son rythme, avec des reprises sur erreur.

Des écritures rejouables. Chaque fiche créée garde l'identifiant de l'autre système — dans un champ personnalisé côté Pipedrive, ou dans une table de correspondance. Rejouer un message deux fois met à jour la même fiche au lieu d'en créer une seconde.

Un rattrapage régulier. Puisqu'un webhook peut perdre des messages, une passe périodique relit ce qui a changé depuis la dernière fois et corrige les écarts. Les webhooks donnent la rapidité, le rattrapage donne la garantie.

Une alerte qui sonne vraiment. Un budget de jetons épuisé, une file qui grossit, un webhook disparu : chacun de ces cas arrête l'intégration sans bruit. L'alerte fait partie de la mise en production, pas des améliorations futures.

Ce qu'il faut préparer avant de demander un devis

Le coût d'une intégration dépend moins de la technique que des décisions à prendre. Arriver avec les réponses fait gagner du temps à tout le monde :

• Quels objets circulent, et dans quel sens. Personnes seulement, ou affaires aussi ? Pipedrive vers l'outil, l'inverse, ou les deux ?
• Qui gagne en cas de conflit. Si la même fiche est modifiée des deux côtés, laquelle fait foi ?
• Le volume. Combien de fiches au départ, combien de changements par jour, et sur quelle offre Pipedrive.
• Qui est prévenu quand ça casse, et par quel canal.

Si votre projet coche l'un des quatre cas du début, c'est exactement ce sur quoi j'interviens : voir comment je travaille sur Pipedrive.