L'API Pipedrive : par où passer, et ce qui se paie
Une API REST en JSON, des webhooks officiels, une authentification par jeton. Voilà les trois portes — et ce qu'aucune ne décide : ce que votre plan autorise, et ce que votre cas demande vraiment.
L'essentiel, si vous ne lisez qu'un paragraphe
- Trois portes officielles. L'API REST (JSON, sans état), les webhooks (créés via
/v1/webhooks), et l'authentification par jeton d'API personnel. - Vous n'avez probablement pas besoin de l'API directement. n8n, Make et Zapier parlent déjà à Pipedrive — la question est laquelle convient à votre cas, pas comment coder.
- Ce qui se tranche avant de coder. Quotas et accès avancés dépendent de votre plan — et ne se lisent pas sans compte. Ça se vérifie avant de s'engager.
Les trois portes de l'API Pipedrive
La référence officielle ouvre par trois mots qui résument tout : « RESTful », « JSON », « stateless » — une API web classique, prévisible, sans état.
Concrètement : vos outils appellent des adresses comme /v1/deals ou /v1/persons, échangent du JSON, et chaque requête se suffit à elle-même. C'est le même schéma que la grande majorité des API SaaS — ce qui compte n'est pas la technique, c'est de savoir quelle porte votre cas emprunte : lire, écrire, ou réagir.
Et il y a une quatrième voie, souvent la meilleure : ne pas appeler l'API du tout, mais passer par une plateforme d'automatisation qui lui parle déjà. C'est le sujet de la section 04.
Vous ne savez pas quelle porte votre cas emprunte ? Décrivez-le dans l'audit de faisabilité — gratuit, réponse sous 48-72 h ouvrées.
Les webhooks : le sens qui rend le service invisible
Pipedrive prévoit officiellement le sens « réagir » : des webhooks créés via l'endpoint /v1/webhooks, qui appellent votre adresse quand un événement se produit dans le CRM.
C'est le mécanisme décrit sur la page webhook de ce site : l'événement se produit, Pipedrive envoie le message à l'adresse inscrite, et votre automatisation enchaîne. Un deal passe à « gagné » → la facture se prépare, l'équipe est notifiée, le client reçoit son email — en secondes, sans que personne n'actualise quoi que ce soit.
Le point de vigilance n'est pas la création du webhook — elle est documentée — mais ce qui le reçoit : une adresse ouverte à tous est une porte sur vos données commerciales. Authentification et vérification d'origine se règlent à la construction, pas après le premier incident.
Un webhook sans protection est une fuite qui attend. L'audit le vérifie avant la première ligne.
L'authentification par jeton, concrètement
Pour un usage interne, la porte d'entrée est le jeton d'API personnel — c'est d'ailleurs ainsi que le nœud Pipedrive de n8n documente sa propre connexion : « Using API token ».
Le jeton se récupère depuis votre compte Pipedrive et s'envoie avec chaque appel : l'API sait qui demande et au nom de quelle entreprise. C'est le mode simple, adapté quand c'est votre outil qui parle à votre Pipedrive. Le mode OAuth — l'autorisation déléguée, celle des applications publiées pour d'autres entreprises — existe aussi, et sert dans le cas des marketplaces : c'est un autre projet, pas une connexion interne.
Le point qui décide vraiment : ce jeton donne accès à vos données commerciales. Il vit dans l'outil qui appelle l'API — jamais dans un tableur, jamais dans un email, et il se révoque si l'outil change. Un audit sérieux le note dans le schéma avant de construire.
Un jeton est une clé, pas un mot de passe à coller partout. Le schéma de l'audit le place au bon endroit.
La question qui précède tout : directement ou via un outil ?
Vous cherchez « API Pipedrive » — mais la vraie question est presque jamais « comment coder les appels ». Elle est : quelle plateforme parle déjà à Pipedrive, et laquelle convient à mon cas.
Les grandes plateformes d'automatisation ont un connecteur Pipedrive prêt : le nœud n8n documente « creating, updating, deleting » et même des opérations d'API personnalisées pour ce qui manque ; Make et Zapier listent Pipedrive dans leurs intégrations. Dans la plupart des cas réels, votre automatisation se construit dans ces outils — sans écrire un seul appel.
L'appel direct à l'API garde du sens quand on veut un programme autonome, sans plateforme, ou une intégration très spécifique au cœur d'un logiciel métier. Le bon choix dépend de ce qui existe déjà chez vous — c'est exactement ce que l'audit confronte avant de recommander quoi que ce soit.
Connecteur tout fait ou appel direct ? L'audit compare sur votre cas réel, pas en théorie.
Ce que l'audit regarde, point par point
L'API existe, les webhooks sont documentés — la réponse dépend de votre Pipedrive : votre plan, vos champs, vos outils en face.
Les quotas exacts et l'accès aux fonctions avancées dépendent de votre abonnement, et ne se vérifient pas depuis l'extérieur : je préfère vous le dire avant de construire plutôt que de promettre. L'audit de faisabilité examine les cinq points de la liste ci-contre, confronte votre plan et vos outils, et vous recevez le schéma du flux, les prérequis et une estimation. C'est gratuit, sans engagement — réponse sous 48-72 h ouvrées.
Le formulaire est juste en dessous : décrivez votre cas, je vous réponds par écrit.
Ce qu'on me demande sur l'API Pipedrive
Non. Les plateformes d'automatisation parlent déjà à Pipedrive — n8n, Make, Zapier ont un connecteur prêt, et c'est là que se construit la plupart des automatisations, sans écrire d'appels. L'API directe reste utile pour un programme autonome ou une intégration très spécifique. Ce que votre cas demande, l'audit le dit avant de choisir.
Dans les réglages de votre compte Pipedrive — c'est le jeton personnel que la documentation des connecteurs (n8n entre autres) demande de copier dans l'outil qui appellera l'API. Attention à ce qu'on en fait : le jeton ouvre vos données commerciales, il vit dans l'outil de connexion, pas dans un tableur ni un email. Si vous n'avez pas à le manipuler vous-même, c'est encore mieux — c'est le schéma que l'audit propose.
Les webhooks font partie de l'API officielle — créés via l'endpoint /v1/webhooks, avec gestion et suppression documentées. Leur fiabilité dans votre projet dépend surtout de ce qui les reçoit : une adresse bien protégée, une file en cas de panne côté réception, une surveillance des échecs. Ce sont ces points-là qui décident de la solidité, et c'est précisément ce que l'audit vérifie avant de construire.
C'est la bonne question à poser — et celle à laquelle je préfère ne pas répondre de mémoire : les quotas et l'accès aux fonctions avancées dépendent de votre abonnement, et ces conditions évoluent. Pendant l'audit, je le vérifie sur votre plan réel et je vous dis ce qui est inclus, ce qui se paie, et ce que votre cas consommera. Vous savez tout avant de vous engager.
L'audit de faisabilité est gratuit et sans engagement. Ensuite, c'est un forfait sur devis selon la complexité — vous connaissez le montant avant de décider. Peuvent s'y ajouter les abonnements des plateformes utilisées (n8n, Make, Zapier), que l'audit chiffre en prérequis. Le verdict arrive par écrit, avec la raison.
Est-ce que ça se branche chez vous ?
3 écrans, 1 minute. Vous recevez sous 48-72 h ouvrées le schéma de ce qui peut se brancher chez vous, les prérequis et une estimation. Gratuit, sans engagement.
Trois étapes, un livrable à chacune
Vous décrivez ce qui se passe à la main aujourd'hui. Je réponds sous 48-72 h ouvrées avec le schéma de ce qui peut se brancher chez vous, les prérequis et une estimation.
Audit de faisabilité
Formulaire en 3 minutes : vos outils, le sens du flux, le déclencheur, le volume. Réponse sous 48-72 h ouvrées avec le schéma du flux, les prérequis et les 3 chantiers prioritaires. Gratuit.
Devis à périmètre écrit
Ce que je branche, ce qui reste validé par vous, le délai et le prix fixe. Le périmètre est écrit avant de commencer, pas ajusté en cours de route.
Construction et passation
Je branche sur vos outils, je teste, je documente. Vous recevez les workflows documentés et la passation — vous gardez tout, et vous n'êtes pas dépendant de moi.