Intégration API HubSpot pour outils internes sur mesure : guide Node + Python (2026)

Vous cherchez encore une clé API HubSpot pour brancher votre intégration API HubSpot ? Arrêtez de chercher. HubSpot a supprimé les clés API statiques le 30 novembre 2022, et le SDK Node actuel (@hubspot/api-client, désormais en v14) n'en accepte de toute façon plus. Le bon identifiant pour un outil interne mono-compte est un token d'accès d'application privée, et ce guide construit une véritable synchronisation HubSpot vers outil interne en Node et en Python, de votre premier appel create contact jusqu'à un webhook à signature vérifiée.

Réponse rapide : une intégration API HubSpot permet à un outil interne sur mesure de lire et d'écrire des données CRM via l'API REST v3 de HubSpot. Pour un outil interne mono-compte, authentifiez-vous avec un token d'accès d'application privée (HubSpot a retiré les clés API en 2022), puis synchronisez les changements en temps réel avec des webhooks plutôt qu'avec du polling.

Voici ce que vous allez construire :

• Authentification par token d'application privée, plus votre premier appel create contact en Node et en Python
• Un récepteur de webhook qui valide X-HubSpot-Signature-v3 avant de faire confiance à une charge utile
• Une synchronisation résistante aux erreurs 429, par lots de 100, vers un enregistrement de ticketing interne ou d'ERP

Comment fonctionne une intégration API HubSpot pour des outils internes sur mesure ?

Une intégration API HubSpot connecte un outil interne sur mesure (une application de ticketing, un ERP, un tableau de bord de facturation, un portail client) au CRM de HubSpot via son API REST v3. Votre outil lit et écrit des objets CRM (contacts, deals, entreprises ou objets personnalisés) en HTTPS avec un token d'accès d'application privée, et les changements en temps réel reviennent via des webhooks.

Imaginez le CRM de HubSpot comme une base de données à laquelle vous parlez en HTTP. Chaque enregistrement est un objet avec un type et un ID. L'intégration crm api hubspot que vous construisez fait deux choses : elle pousse des données vers HubSpot (créer un contact à l'ouverture d'un ticket) et elle en extrait (lire un deal quand votre tableau de bord interne s'affiche).

La synchronisation fonctionne dans l'un de deux sens. Une synchronisation unidirectionnelle copie les changements de HubSpot vers votre outil, ou de votre outil vers HubSpot. Une synchronisation bidirectionnelle fait les deux et nécessite une protection contre les boucles, que nous verrons plus loin. Et plutôt que de demander à HubSpot « quoi de neuf ? » toutes les minutes (le polling), vous enregistrez un webhook pour que HubSpot vous prévienne dès qu'un enregistrement change.

Si vous préférez posséder vos données plutôt que d'intégrer un CRM hébergé, auto-héberger un CRM open source est une autre voie qui mérite d'être pesée avant de vous engager. Mais si HubSpot est déjà votre source de vérité, c'est l'API qui permet à tout le reste de lui parler.

Pour un outil interne mono-compte, vous n'avez besoin ni d'OAuth ni d'une fiche sur l'app marketplace. Un token d'application privée et un webhook, c'est toute l'intégration.

L'authentification en 2026 : pourquoi il n'y a plus de clé API HubSpot

Pour l'authentification API HubSpot d'un outil interne mono-compte, utilisez un token d'accès d'application privée. C'est un bearer token statique que vous générez une seule fois dans votre compte HubSpot, restreint exactement aux objets que votre outil manipule. Il n'y a ni flux de rafraîchissement ni expiration. OAuth existe pour les applications publiques multi-comptes, pas pour le tableau de bord que votre équipe ops fait tourner en interne.

Token d'application privée contre la clé API dépréciée

Voici le piège qui fait trébucher la moitié des développeurs qui tombent sur cette page de résultats. HubSpot a retiré les clés API le 30 novembre 2022, et elles ne sont plus du tout supportées. L'autocomplétion suggère encore « hubspot api key » parce que le réflexe n'a pas encore rattrapé le changement, mais il n'y a plus aucune clé à récupérer. Passez plutôt par une hubspot private app : créez-la dans Settings, accordez-lui les scopes dont elle a besoin, et copiez le token d'accès depuis l'onglet Auth. L'aperçu des private apps de HubSpot détaille la mise en place.

Deux règles concernant le token lui-même. Accordez le moindre privilège : si votre outil ne fait que lire des deals et écrire des contacts, demandez crm.objects.contacts.write et crm.objects.deals.read, rien de plus. Et conservez le token dans une variable d'environnement ou un gestionnaire de secrets, envoyé dans l'en-tête Authorization: Bearer, jamais codé en dur et jamais expédié au navigateur.

Le verdict est simple. Pour un outil interne, utilisez un token d'accès d'application privée. Ne passez à OAuth que si cet outil devient plus tard une application publique multi-comptes que d'autres entreprises installent dans leurs propres portails.

Votre premier appel API HubSpot : créer un contact en Node et en Python

Le premier appel classique est create contact, et les SDK officiels le réduisent à quelques lignes. Installez le client, initialisez-le avec votre token d'application privée depuis l'environnement, puis créez un contact et relisez un deal. C'est exactement le même schéma que vous réutiliserez pour les entreprises, les tickets et les appels api objets personnalisés hubspot, seul le type d'objet change.

Voici la version Node avec @hubspot/api-client (v14) :

// npm i @hubspot/api-client   (v14.x)
import { Client } from "@hubspot/api-client";

// Token d'application privée depuis un gestionnaire de secrets ou une variable d'env, jamais codé en dur
const hubspot = new Client({ accessToken: process.env.HUBSPOT_PRIVATE_APP_TOKEN });

// Créer un contact
const { id } = await hubspot.crm.contacts.basicApi.create({
  properties: {
    email: "[email protected]",
    firstname: "Ada",
    lastname: "Lovelace",
    lifecyclestage: "lead",
  },
  associations: [],
});
console.log("Created contact", id);

// Lire un deal par son ID
const deal = await hubspot.crm.deals.basicApi.getById(
  "1234567890",
  ["dealname", "amount", "dealstage"],
);
console.log(deal.properties.dealname, deal.properties.amount);

Et la même chose en Python avec hubspot-api-client (v12) :

# pip install hubspot-api-client   (v12.x)
import os
from hubspot import HubSpot
from hubspot.crm.contacts import SimplePublicObjectInputForCreate

# Token d'application privée depuis l'environnement, pas dans le contrôle de version
client = HubSpot(access_token=os.environ["HUBSPOT_PRIVATE_APP_TOKEN"])

# Créer un contact
contact = client.crm.contacts.basic_api.create(
    simple_public_object_input_for_create=SimplePublicObjectInputForCreate(
        properties={
            "email": "[email protected]",
            "firstname": "Ada",
            "lastname": "Lovelace",
            "lifecyclestage": "lead",
        }
    )
)
print("Created contact", contact.id)

# Lire un deal par son ID
deal = client.crm.deals.basic_api.get_by_id(
    deal_id="1234567890",
    properties=["dealname", "amount", "dealstage"],
)
print(deal.properties["dealname"], deal.properties["amount"])

Astuce de pro : testez d'abord sur un sandbox développeur HubSpot, jamais en production. Un appel create mal formé en production laisse de vrais enregistrements parasites que votre équipe commerciale devra nettoyer. Le token, les scopes et le modèle d'objets se comportent à l'identique dans le sandbox.

Comment synchroniser HubSpot avec un outil interne en temps réel ?

Utilisez des webhooks, pas du polling. Enregistrez un abonnement webhook dans votre application privée pour l'objet et l'événement qui vous intéressent (par exemple deal.propertyChange), pointez-le vers un endpoint HTTPS que vous hébergez, et HubSpot vous envoie un petit tableau JSON en POST dès qu'un changement correspondant survient. Ne faites du polling que lorsqu'aucun abonnement n'existe pour ce que vous devez surveiller.

Le gain, c'est l'efficacité. Le polling demande « quoi de neuf ? » toutes les minutes et consomme votre rate limit à le faire ; un webhook vous prévient simplement au moment où un deal change. Cette différence compte à l'échelle, et les webhooks sont désormais courants, pas exotiques : le State of the API Report 2025 de Postman, une enquête menée auprès de plus de 5 700 développeurs, a constaté qu'environ la moitié des équipes s'appuient dessus.

Enregistrez l'abonnement dans l'onglet Webhooks de votre application privée, définissez l'URL cible et choisissez les événements. HubSpot envoie un tableau d'objets événements, chacun portant le subscriptionType, l'objectId, et ce qui a changé. Voici un squelette de récepteur en Node avec Express :

import express from "express";

const app = express();
// Capturer le corps brut : il faut les octets exacts pour valider la signature ensuite
app.use(express.json({
  verify: (req, _res, buf) => { req.rawBody = buf.toString("utf8"); },
}));

// HubSpot POSTe un tableau d'événements vers cette URL
app.post("/webhooks/hubspot", (req, res) => {
  const events = req.body; // [{ subscriptionType: "deal.propertyChange", objectId: 1234, ... }]
  for (const event of events) {
    console.log("HubSpot event:", event.subscriptionType, event.objectId);
    // Ne faites PAS confiance à cette charge utile pour l'instant. La section suivante la valide avant qu'on agisse.
  }
  res.sendStatus(200);
});

app.listen(3000, () => console.log("Listening on :3000"));

C'est ici que la construction devient concrète. Imaginez que vous synchronisiez un deal vers l'enregistrement ERP d'un petit fabricant : le webhook se déclenche, votre handler crée ou met à jour le ticket ERP correspondant, et votre équipe ops voit le changement sans toucher à HubSpot. C'est la même approche temps réel que nous utilisons pour synchroniser un agent vocal avec un CRM, sauf que le déclencheur est un changement de propriété plutôt qu'un appel téléphonique. Un avertissement : le squelette ci-dessus fait confiance à tout ce qu'on lui POSTe. Corrigez cela avant de passer en production.

Valider les signatures de webhook (v3) pour ne jamais faire confiance à une charge utile forgée

Validez chaque webhook entrant avec la signature v3. HubSpot signe chaque requête avec le secret de votre application et envoie deux en-têtes, X-HubSpot-Signature-v3 et X-HubSpot-Request-Timestamp. Rejetez tout ce qui a plus de 5 minutes, reconstruisez la chaîne source comme méthode + URL complète + corps brut + timestamp, appliquez un HMAC-SHA256 avec le secret de l'application, encodez en base64, et comparez en temps constant.

Si vous sautez cette étape, n'importe qui devinant l'URL de votre webhook peut forger une mise à jour de deal. La validation n'est pas optionnelle. La documentation sur la validation des requêtes et le changelog des signatures v3 de HubSpot détaillent la recette exacte. La voici sous forme de middleware Express prêt à l'emploi :

import crypto from "crypto";

const CLIENT_SECRET = process.env.HUBSPOT_APP_SECRET; // depuis les paramètres de votre application privée
const MAX_AGE_MS = 5 * 60 * 1000; // rejeter tout ce qui a plus de 5 minutes

export function validateHubSpotSignature(req, res, next) {
  const signature = req.header("X-HubSpot-Signature-v3");
  const timestamp = req.header("X-HubSpot-Request-Timestamp");

  // 1. Rejeter les requêtes périmées (protection contre le rejeu)
  if (!signature || !timestamp || Date.now() - Number(timestamp) > MAX_AGE_MS) {
    return res.sendStatus(401);
  }

  // 2. Reconstruire la chaîne source exacte : méthode + URL complète + corps brut + timestamp
  const uri = `https://${req.get("host")}${req.originalUrl}`;
  const source = `${req.method}${uri}${req.rawBody}${timestamp}`;

  // 3. HMAC-SHA256 avec le secret de l'application, encodé en base64
  const hash = crypto
    .createHmac("sha256", CLIENT_SECRET)
    .update(source, "utf8")
    .digest("base64");

  // 4. Comparaison en temps constant avec l'en-tête
  const expected = Buffer.from(hash);
  const received = Buffer.from(signature);
  if (expected.length !== received.length ||
      !crypto.timingSafeEqual(expected, received)) {
    return res.sendStatus(401);
  }
  next();
}

La même vérification sous forme de fonction Python, pour couvrir les deux stacks :

import base64
import hashlib
import hmac
import os
import time

CLIENT_SECRET = os.environ["HUBSPOT_APP_SECRET"].encode("utf-8")
MAX_AGE_MS = 5 * 60 * 1000  # 5 minutes

def is_valid_signature(method, uri, body, signature, timestamp):
    # 1. Rejeter les requêtes périmées
    if not signature or not timestamp:
        return False
    if int(time.time() * 1000) - int(timestamp) > MAX_AGE_MS:
        return False

    # 2. méthode + URL complète + corps brut + timestamp
    source = f"{method}{uri}{body}{timestamp}".encode("utf-8")

    # 3. HMAC-SHA256, base64
    digest = hmac.new(CLIENT_SECRET, source, hashlib.sha256).digest()
    expected = base64.b64encode(digest).decode("utf-8")

    # 4. Comparaison en temps constant
    return hmac.compare_digest(expected, signature)

Le piège qui coûte une après-midi à pas mal de monde : HubSpot signe l'URL cible complète, schéma, hôte et chemin ensemble. Derrière un proxy, un load balancer ou un tunnel ngrok, req.get("host") peut renvoyer l'hôte interne au lieu de l'hôte public que HubSpot a signé. Si la validation échoue sans arrêt sur une charge utile dont vous êtes certain qu'elle est légitime, journalisez l'URI exacte que vous avez reconstruite et comparez-la caractère par caractère à votre URL de webhook publique.

Rate limits, erreurs 429 et API batch : ce que nous avons fait tourner en production

Les applications privées disposent d'environ 10 requêtes par seconde (100 par tranche de 10 secondes en Free/Starter, 190 par tranche de 10 secondes en Pro/Enterprise), avec un plafond journalier compris entre 250 000 et 1 000 000. Le piège : CRM Search a son propre plafond séparé de 4 requêtes par seconde, et les endpoints batch acceptent un maximum de 100 enregistrements par requête. Les guidelines d'usage de HubSpot détaillent les paliers.

Voilà où la théorie a rencontré un tableau de bord de staging passé au rouge. Pendant un backfill ce printemps, nous avons poussé environ 8 000 enregistrements existants vers HubSpot depuis un outil de ticketing interne, en enrichissant chacun via une recherche CRM Search. Nous faisions tourner @hubspot/api-client v14 côté Node et hubspot-api-client v12 pour un worker d'enrichissement Python. Les écritures en masse se sont bien passées. Les appels Search se sont écroulés en moins d'une minute, parce que notre worker tirait du Search à environ 15 req/s contre un plafond strict de 4 req/s que nous n'avions pas budgété séparément.

Deux changements ont résolu le problème. D'abord, un wrapper de retry qui lit les en-têtes de réponse X-HubSpot-RateLimit-* et recule en cas de 429 :

// Enveloppe n'importe quel appel HubSpot ; réessaie sur un 429 avec backoff exponentiel
async function withRetry(fn, maxRetries = 5) {
  let attempt = 0;
  while (true) {
    try {
      return await fn();
    } catch (err) {
      const status = err.code ?? err.response?.status;
      if (status !== 429 || attempt >= maxRetries) throw err;

      // Respecter la fenêtre de reset de HubSpot si l'en-tête est présent
      const headers = err.response?.headers ?? {};
      const resetMs = Number(headers["x-hubspot-ratelimit-interval-milliseconds"]) || 0;
      const backoff = Math.max(resetMs, 2 ** attempt * 500); // 0.5s, 1s, 2s, 4s...

      console.warn(`429 hit, retry ${attempt + 1} in ${backoff}ms`);
      await new Promise((r) => setTimeout(r, backoff));
      attempt++;
    }
  }
}

Ensuite, nous avons arrêté d'écrire les enregistrements un par un. Le endpoint batch accepte jusqu'à 100 enregistrements par POST /crm/v3/objects/{objectType}/batch/create, donc nous avons découpé le backfill en 80 appels batch au lieu de 8 000 POST individuels :

// Les endpoints batch de HubSpot acceptent au maximum 100 enregistrements par requête
function chunk(arr, size = 100) {
  const out = [];
  for (let i = 0; i < arr.length; i += size) out.push(arr.slice(i, i + size));
  return out;
}

// POST /crm/v3/objects/contacts/batch/create, découpé en lots de 100
async function batchCreateContacts(records) {
  for (const group of chunk(records, 100)) {
    const inputs = group.map((r) => ({
      properties: { email: r.email, firstname: r.firstName, lastname: r.lastName },
      associations: [],
    }));
    await withRetry(() => hubspot.crm.contacts.batchApi.create({ inputs }));
    console.log(`Wrote ${group.length} contacts`);
  }
}

Brider le worker Search à 4 req/s et regrouper les écritures en batch a transformé une exécution noyée sous les retries en une exécution qui s'est terminée sans bruit. Si vous ne retenez qu'un chiffre de cette section, retenez 4 : le plafond de CRM Search est la limite qui mord en production, et c'est celle que tous les articles récapitulatifs oublient de mentionner. Au passage, l'ancien plafond batch de « 10 pour les contacts » a disparu ; il est aujourd'hui de 100 pour tous les types d'objets.

Passer en bidirectionnel : réécrire les changements dans HubSpot sans boucle infinie

Une synchronisation bidirectionnelle réécrit les changements dans HubSpot depuis votre outil interne, en plus de les lire. Le danger, c'est une boucle de rétroaction : votre réécriture déclenche le webhook même qui a lancé votre handler, qui réécrit à nouveau, indéfiniment. Prévenez cela avec une clé d'idempotence (ignorer les changements déjà appliqués) et un drapeau de source (ignorer les événements entrants causés par votre propre outil).

const processed = new Set(); // utilisez Redis ou une contrainte DB unique en production

async function writeBackToHubSpot(record) {
  // Clé de déduplication : id de l'objet + hash du changement qu'on s'apprête à appliquer
  const key = `${record.id}:${record.updatedHash}`;
  if (processed.has(key)) return; // ce changement exact a déjà été synchronisé
  processed.add(key);

  await withRetry(() =>
    hubspot.crm.contacts.basicApi.update(record.id, {
      // Marquer la source pour que le webhook résultant soit ignoré par notre propre récepteur
      // (vérifier source: "internal-tool" avant d'agir sur un événement entrant)
      properties: { internal_status: record.status, last_sync_source: "internal-tool" },
    })
  );
}

Le mécanisme est minime, mais l'oublier, c'est ainsi qu'une synchronisation double discrètement votre volume d'écriture du jour au lendemain. Une fois les données propres dans les deux sens, les équipes les réinjectent souvent en aval dans un pipeline AI SDR ou une couche de reporting. Le tutoriel d'intégration HubSpot de Nango est une bonne référence, uniquement en Node, si vous voulez un second avis sur la synchronisation bidirectionnelle, même s'il vous faudra porter vous-même l'idée de prévention des boucles.

Faut-il construire cela en interne ou faire appel à un partenaire d'intégration ?

Construisez en interne quand la synchronisation est petite, stable et prise en charge : un flux unidirectionnel, une poignée d'objets, et un ingénieur capable d'absorber les changements cassants de HubSpot, environ deux fois par an. Faites appel à un partenaire quand vous avez besoin d'une synchronisation bidirectionnelle, d'une modélisation d'objets personnalisés, ou quand personne dans l'équipe ne peut prendre en charge la maintenance continue. Le facteur décisif est rarement la construction initiale ; c'est qui la surveille un an plus tard.

Voici une checklist honnête. Construisez-le vous-même si : la direction est unidirectionnelle, vous synchronisez des objets standard, vous avez un développeur capable d'héberger un endpoint webhook, et quelqu'un remarquera si une charge utile commence à échouer. Tout ce qui précède est votre plan de construction.

Faites appel à un partenaire si : vous avez besoin d'une synchronisation bidirectionnelle avec prévention des boucles sur plusieurs objets, vous modélisez des objets personnalisés avec des associations typées, vous connectez plusieurs systèmes (HubSpot plus un ERP plus la facturation), ou la personne censée en assurer la maintenance est déjà saturée. HubSpot utilise un versioning d'API basé sur des dates, avec des changements cassants seulement deux fois par an environ, ce qui paraît anodin jusqu'à ce que l'un d'eux tombe pendant votre semaine la plus chargée, sans personne pour s'en occuper. C'est cette traîne de maintenance, pas le premier déploiement, qui coule discrètement les intégrations internes. Si vous préférez ne pas la porter vous-même, c'est là qu'interviennent nos services d'intégration CRM sur mesure.

Points clés à retenir

• Il n'y a plus de clé API HubSpot. Utilisez un token d'accès d'application privée pour un outil interne mono-compte ; OAuth est réservé aux applications publiques multi-comptes.
• Validez toujours X-HubSpot-Signature-v3 avant de faire confiance à une charge utile de webhook. Reconstruisez la chaîne source avec l'URL cible complète.
• Respectez le plafond de 4 req/s pour CRM Search et regroupez les grosses écritures par lots de 100 avec un backoff sur les 429.
• Préférez les webhooks au polling pour la synchronisation en temps réel, et une intégration HubSpot n'est qu'une pièce d'une stack plus large d'outils IA pour les entreprises.

Coincé sur le volet maintenance, ou vous voulez un second regard avant de déployer ? Réservez une consultation d'intégration gratuite. Aucune pression dans un sens ou dans l'autre ; le code ci-dessus est à vous, que vous preniez rendez-vous ou non.

Questions fréquentes

Ai-je encore besoin d'une clé API HubSpot en 2026 ?

Non. HubSpot a retiré les clés API statiques le 30 novembre 2022, et elles ne sont plus du tout supportées. L'autocomplétion suggère encore « hubspot api key » par habitude, mais il n'y a rien à récupérer. Pour un outil interne mono-compte, créez une application privée dans Settings et utilisez son token d'accès à la place.

Quelle est la différence entre un token d'application privée et OAuth pour HubSpot ?

Un token d'accès d'application privée est un identifiant statique pour un seul compte HubSpot, sans expiration ni flux de rafraîchissement, idéal pour un outil interne. OAuth 2.0 est destiné aux applications publiques multi-comptes que d'autres entreprises installent dans leurs propres portails ; ses tokens expirent en environ six heures et nécessitent un cycle de rafraîchissement.

Quelles sont les limites de débit de l'API HubSpot en 2026 ?

Les applications privées disposent d'environ 10 requêtes par seconde (100 par tranche de 10 secondes en Free/Starter, 190 en Pro/Enterprise), avec un plafond journalier de 250 000 à 1 000 000. L'API CRM Search est plafonnée séparément à 4 requêtes par seconde, et les endpoints batch acceptent un maximum de 100 enregistrements par requête.

Comment valider une signature de webhook HubSpot ?

Utilisez la recette v3 : rejetez les requêtes dont X-HubSpot-Request-Timestamp a plus de cinq minutes, puis construisez une chaîne source composée de la méthode, plus l'URL cible complète, plus le corps brut, plus le timestamp. Appliquez-lui un HMAC-SHA256 avec le secret de votre application, encodez le résultat en base64, et comparez-le à X-HubSpot-Signature-v3 en temps constant.

Quel SDK HubSpot utiliser, Node ou Python ?

Les deux sont officiels et maintenus. Node utilise @hubspot/api-client (v14) et Python utilise hubspot-api-client (v12). Ils exposent le même modèle d'objets CRM v3, donc choisissez celui qui correspond à votre stack. Ce guide fournit un code d'authentification et de validation de signature identique dans les deux langages.

Comment synchroniser HubSpot avec un outil interne sur mesure en temps réel ?

Enregistrez un abonnement webhook dans votre application privée pour l'objet et l'événement qui vous intéressent, puis hébergez un endpoint HTTPS vers lequel HubSpot envoie un POST quand un changement correspondant survient. Validez la signature, puis écrivez le changement dans votre outil interne. Ne faites du polling que lorsqu'aucun abonnement webhook ne couvre ce dont vous avez besoin.

Qu'est-ce qu'une HubSpot Service Key et faut-il l'utiliser ?

Une Service Key est un identifiant au niveau du compte, données uniquement, que HubSpot a mis en bêta publique en février 2026. Elle vise les tâches serveur qui ne touchent qu'aux données. Pour un outil interne standard aujourd'hui, un token d'accès d'application privée reste le choix par défaut le plus sûr et le mieux documenté ; considérez les Service Keys comme une bêta tant qu'elles n'ont pas atteint la disponibilité générale.

Puis-je tester une intégration HubSpot sans toucher à la production ?

Oui. Créez un sandbox développeur HubSpot et pointez votre token d'application privée vers lui. Les scopes, le modèle d'objets, les webhooks et les rate limits se comportent comme en production, ce qui vous permet de créer des contacts de test et de déclencher des webhooks sans laisser de faux enregistrements que votre équipe commerciale devra nettoyer plus tard.

Combien d'enregistrements l'API batch de HubSpot peut-elle traiter à la fois ?

Les endpoints batch (POST /crm/v3/objects/{objectType}/batch/create et ses équivalents update et upsert) acceptent un maximum de 100 enregistrements par requête. Découpez les charges plus volumineuses en groupes de 100. L'ancien plafond de « 10 enregistrements pour les contacts » que certains tutoriels citent encore a été supprimé ; c'est 100 qui s'applique désormais pour tous les types d'objets.

Faut-il construire cela en interne ou faire appel à une agence ?

Construisez en interne quand la synchronisation est unidirectionnelle, utilise des objets standard, et dispose d'un responsable capable d'absorber les changements cassants de HubSpot deux fois par an. Faites appel à un partenaire pour une synchronisation bidirectionnelle, une modélisation d'objets personnalisés, ou quand personne ne peut prendre en charge la maintenance. Le premier déploiement est facile ; c'est l'année d'entretien qui suit qui représente le vrai coût.