Integrare API HubSpot pentru instrumente interne personalizate: Ghid Node + Python (2026)

Integrare API HubSpot pentru instrumente interne personalizate: Ghid Node + Python (2026)

Încă cauți o cheie API HubSpot pentru a configura integrarea ta API HubSpot? Nu mai căuta. HubSpot a eliminat cheile API statice pe 30 noiembrie 2022, iar SDK-ul curent pentru Node (@hubspot/api-client, acum la v14) nici nu ar accepta una oricum. Credencialul corect pentru un instrument intern destinat unui singur cont este un token de acces pentru aplicație privată, iar acest ghid construiește o sincronizare reală HubSpot-către-instrument-intern atât în Node, cât și în Python, de la primul tău apel create contact până la un webhook validat prin semnătură.

Răspuns rapid: O integrare API HubSpot permite unui instrument intern personalizat să citească și să scrie date CRM prin API-ul REST v3 al HubSpot. Pentru un instrument intern destinat unui singur cont, autentifică-te cu un token de acces pentru aplicație privată (HubSpot a retras cheile API în 2022), apoi sincronizează modificările în timp real cu webhook-uri în loc de polling.

Iată ce vei construi:

• Autentificare cu token de aplicație privată plus primul tău apel create contact în Node și Python
• Un receptor de webhook care validează X-HubSpot-Signature-v3 înainte de a considera payload-ul sigur
• O sincronizare sigură la eroarea 429, în loturi de 100, către o înregistrare internă de tip ticketing sau ERP

Cum funcționează integrarea API HubSpot pentru instrumente interne personalizate?

O integrare API HubSpot conectează un instrument intern personalizat (o aplicație de ticketing, un ERP, un dashboard de facturare, un portal pentru clienți) la CRM-ul HubSpot prin API-ul său REST v3. Instrumentul tău citește și scrie obiecte CRM (contacte, tranzacții, companii sau obiecte personalizate) peste HTTPS cu un token de acces pentru aplicație privată, iar modificările în timp real revin prin webhook-uri.

Gândește-te la CRM-ul HubSpot ca la o bază de date cu care comunici prin HTTP. Fiecare înregistrare este un obiect cu un tip și un ID. hubspot crm api integration pe care o construiești are două roluri: împinge date în HubSpot (creează un contact când se deschide un tichet) și extrage date din el (citește o tranzacție când dashboard-ul tău intern se randează).

Sincronizarea rulează într-una dintre cele două direcții. O sincronizare unidirecțională copiază modificările din HubSpot în instrumentul tău sau din instrumentul tău în HubSpot. O sincronizare bidirecțională face ambele și necesită protecție împotriva buclelor infinite, aspect pe care îl vom aborda mai târziu. Și în loc să întrebi HubSpot „ceva nou?” în fiecare minut (polling), înregistrezi un webhook astfel încât HubSpot să îți spună imediat ce se schimbă o înregistrare.

Dacă preferi să deții datele complet în loc să integrezi un CRM găzduit, auto-găzduirea unui CRM open-source este o cale diferită care merită cântărită înainte de a te angaja. Dar dacă HubSpot este deja sursa ta principală de adevăr, API-ul este modul în care totul else comunică cu el.

Pentru un instrument intern destinat unui singur cont, nu ai nevoie de OAuth sau de o listare în marketplace-ul de aplicații. Un token de aplicație privată și un webhook reprezintă întreaga integrare.

Autentificare în 2026: De ce nu mai există cheie API HubSpot

Pentru autentificarea API HubSpot pe un instrument intern destinat unui singur cont, folosește un token de acces pentru aplicație privată. Este un token bearer static pe care îl generezi o singură dată în contul tău HubSpot, limitat exact la obiectele pe care le atinge instrumentul tău. Nu există flux de reîmprospătare și nu expiră. OAuth există pentru aplicații publice, multi-cont, nu pentru dashboard-ul pe care echipa ta de operațiuni îl rulează intern.

Token aplicație privată vs. cheia API depreciată

Iată capcana în care cade jumătate dintre dezvoltatorii care ajung la acest rezultat în motorul de căutare. HubSpot a retras cheile API pe 30 noiembrie 2022, iar acestea sunt acum complet neacceptate. Autocomplete-ul sugerează încă „hubspot api key” deoarece memoria musculară nu s-a actualizat, dar nu există nicio cheie de preluat. Folosește în schimb o aplicație privată hubspot: creeaz-o în Setări, acordă domeniile (scopes) de care are nevoie și copiază tokenul de acces din tab-ul Auth. Prezentarea generală a aplicațiilor private HubSpot acoperă configurarea.

Două reguli pentru token în sine. Acordă privilegiul minim: dacă instrumentul tău doar citește tranzacții și scrie contacte, solicită crm.objects.contacts.write și crm.objects.deals.read, nimic mai mult. Și păstrează tokenul într-o variabilă de mediu sau într-un manager de secrete, trimis în header-ul Authorization: Bearer, niciodată hard-coded și niciodată trimis către browser.

Verdictul este simplu. Pentru un instrument intern, folosește un token de acces pentru aplicație privată. Recurge la OAuth doar dacă acesta devine ulterior o aplicație publică, multi-cont, pe care alte companii o instalează în propriile lor portaluri.

Primul tău apel API HubSpot: Crearea unui contact în Node și Python

Apelul canonic inițial este create contact, iar SDK-urile oficiale îl fac în câteva linii. Instalează clientul, inițializează-l cu tokenul tău de aplicație privată din mediul de execuție, apoi creează un contact și citește înapoi o tranzacție. Acesta este același model pe care îl vei refolosi pentru companii, tichete și apeluri hubspot custom objects api, doar tipul obiectului se schimbă.

Iată versiunea Node cu @hubspot/api-client (v14):

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

// Private app token from a secret manager or env var, never hard-coded
const hubspot = new Client({ accessToken: process.env.HUBSPOT_PRIVATE_APP_TOKEN });

// Create a 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);

// Read a deal by ID
const deal = await hubspot.crm.deals.basicApi.getById(
  "1234567890",
  ["dealname", "amount", "dealstage"],
);
console.log(deal.properties.dealname, deal.properties.amount);

Și același lucru în Python cu hubspot-api-client (v12):

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

# Private app token from the environment, not source control
client = HubSpot(access_token=os.environ["HUBSPOT_PRIVATE_APP_TOKEN"])

# Create a 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)

# Read a deal by ID
deal = client.crm.deals.basic_api.get_by_id(
    deal_id="1234567890",
    properties=["dealname", "amount", "dealstage"],
)
print(deal.properties["dealname"], deal.properties["amount"])

Sfat pro: testează într-un sandbox de dezvoltator HubSpot, niciodată direct în producție la început. Un apel de creare malformat în producție lasă înregistrări junk reale pe care echipa ta de vânzări trebuie să le curățe. Tokenul, domeniile (scopes) și modelul de obiecte se comportă identic în sandbox.

Cum sincronizezi HubSpot cu un instrument intern în timp real?

Folosește webhook-uri, nu polling. Înregistrează o subscripție webhook în aplicația ta privată pentru obiectul și evenimentul care te interesează (de exemplu, `deal.propertyChange*), indică un endpoint HTTPS găzduit de tine, iar HubSpot îți va trimite un mic array JSON în momentul în care apare o modificare corespunzătoare. Folosește polling doar când nu există o subscripție pentru ceea ce trebuie să monitorizezi.

Beneficiul este eficiența. Polling-ul întreabă „ceva nou?” în fiecare minut și îți consumă limita de rate făcând asta; un webhook îți spune doar în momentul în care o tranzacție se schimbă. Această diferență contează la scară mare, iar webhook-urile sunt acum mainstream, nu exotice: Raportul State of the API din 2025 al Postman, un sondaj al peste 5.700 de dezvoltatori, a constatat că aproximativ jumătate dintre echipe se bazează pe ele.

Înregistrează subscripția sub tab-ul Webhooks al aplicației tale private, setează URL-ul țintă și alege evenimentele. HubSpot trimite un array de obiecte eveniment, fiecare purtând subscriptionType, objectId și ceea ce s-a schimbat. Iată un stub de receptor în Node cu Express:

import express from "express";

const app = express();
// Capture the raw body: you need the exact bytes to validate the signature next
app.use(express.json({
  verify: (req, _res, buf) => { req.rawBody = buf.toString("utf8"); },
}));

// HubSpot POSTs an array of events to this 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);
    // Do NOT trust this payload yet. The next section validates it before we act.
  }
  res.sendStatus(200);
});

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

Aici devine serioasă construcția pas cu pas. Să zicem că sincronizezi o tranzacție într-o înregistrare ERP a unui mic producător: webhook-ul se declanșează, handler-ul tău creează sau actualizează tichetul ERP corespunzător, iar echipa ta de operațiuni vede modificarea fără a atinge HubSpot. Este aceeași abordare în timp real pe care o folosim pentru a sincroniza un agent vocal cu un CRM, doar că trigger-ul este o modificare de proprietate în loc de un apel telefonic. Un avertisment: stub-ul de mai sus are încredere în orice i se postează. Rezolvă asta înainte de a merge live.

Validarea semnăturilor Webhook (v3) pentru a nu avea încredere niciodată într-un payload falsificat

Validează fiecare webhook incoming cu semnătura v3. HubSpot semnează fiecare cerere cu secretul aplicației tale și trimite două headere, X-HubSpot-Signature-v3 și X-HubSpot-Request-Timestamp. Respinge orice este mai vechi de 5 minute, reconstruiește șirul sursă ca method + full URL + raw body + timestamp, aplică HMAC-SHA256 cu secretul aplicației, encodează base64 și compară în timp constant.

Dacă sară peste acest pas, oricine ghicește URL-ul webhook-ului tău poate falsifica o actualizare de tranzacție. Validarea nu este opțională. Documentația HubSpot despre validarea cererilor și changelog-ul semnăturilor v3 detaliază rețeta exactă. Iată-o ca middleware Express drop-in:

import crypto from "crypto";

const CLIENT_SECRET = process.env.HUBSPOT_APP_SECRET; // from your private app settings
const MAX_AGE_MS = 5 * 60 * 1000; // reject anything older than 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. Reject stale requests (replay protection)
  if (!signature || !timestamp || Date.now() - Number(timestamp) > MAX_AGE_MS) {
    return res.sendStatus(401);
  }

  // 2. Rebuild the exact source string: method + full URL + raw body + timestamp
  const uri = `https://${req.get("host")}${req.originalUrl}`;
  const source = `${req.method}${uri}${req.rawBody}${timestamp}`;

  // 3. HMAC-SHA256 with the app secret, base64-encoded
  const hash = crypto
    .createHmac("sha256", CLIENT_SECRET)
    .update(source, "utf8")
    .digest("base64");

  // 4. Constant-time compare against the header
  const expected = Buffer.from(hash);
  const received = Buffer.from(signature);
  if (expected.length !== received.length ||
      !crypto.timingSafeEqual(expected, received)) {
    return res.sendStatus(401);
  }
  next();
}

Aceeași verificare ca funcție Python, astfel încât ambele stive sunt acoperite:

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. Reject stale requests
    if not signature or not timestamp:
        return False
    if int(time.time() * 1000) - int(timestamp) > MAX_AGE_MS:
        return False

    # 2. method + full URL + raw body + 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. Constant-time compare
    return hmac.compare_digest(expected, signature)

Capcana care costă oamenii o după-amiază: HubSpot semnează URL-ul țintă complet, schema, gazda și calea împreună. În spatele unui proxy, load balancer sau tunel ngrok, req.get("host") poate raporta gazda internă în loc de cea publică pe care HubSpot a semnat-o. Dacă validarea eșuează continuu pentru un payload despre care ești sigur că este legitim, loghează URI-ul exact pe care l-ai reconstruit și compară-l cu URL-ul tău public de webhook, caracter cu caracter.

Limite de rate, erori 429 și Batch API: Ce am rulat în producție

Aplicațiile private primesc aproximativ 10 cereri pe secundă (100 la 10 secunde pe Free/Starter, 190 la 10 secunde pe Pro/Enterprise) cu un cap zilnic între 250.000 și 1.000.000. Capcana: CRM Search este limitat separat la 4 cereri pe secundă, iar endpoint-urile batch acceptă un maxim de 100 de înregistrări per cerere. Ghidurile de utilizare HubSpot listează tier-ele.

Iată unde teoria a întâlnit un dashboard de staging roșu. În timpul unei umpleri inițiale (backfill) în această primăvară, am împins aproximativ 8.000 de înregistrări existente în HubSpot dintr-un instrument intern de ticketing și am îmbogățit fiecare cu o căutare CRM Search. Rulam @hubspot/api-client v14 pe partea Node și hubspot-api-client v12 pentru un worker de îmbogățire Python. Scrierile bulk au mers bine. Apelurile Search au cedat într-un minut, deoarece worker-ul nostru lansa Search la aproximativ 15 req/s față de un plafon dur de 4 req/s pentru care nu bugetaserăm separat.

Două modificări au rezolvat problema. Mai întâi, un wrapper de retry care citește headerele de răspuns X-HubSpot-RateLimit-* și reduce ritmul (backs off) la o eroare 429:

// Wrap any HubSpot call; retries on 429 with exponential backoff
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;

      // Honor HubSpot's reset window if the header is present
      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++;
    }
  }
}

În al doilea rând, am încetat să scriem înregistrările una câte una. Endpoint-ul batch acceptă până la 100 de înregistrări per POST /crm/v3/objects/{objectType}/batch/create, așa că am fragmentat backfill-ul în 80 de apeluri batch în loc de 8.000 de POST-uri individuale:

// HubSpot batch endpoints accept at most 100 records per request
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, chunked to 100 at a time
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`);
  }
}

Limitarea worker-ului Search la 4 req/s și batching-ul scrierilor au transformat o execuție care se îneca în retry-uri într-una care s-a finalizat liniștit. Dacă reții un singur număr din această secțiune, fie el 4: capul CRM Search este limita care mușcă în producție și este cea pe care fiecare articol de roundup uită să o menționeze. Apropo, vechiul plafon batch de „10 pentru contacte” a dispărut; actualul este 100 across tipuri de obiecte.

Mergerea bidirecțională: Scrierea modificărilor înapoi în HubSpot fără bucle infinite

O sincronizare bidirecțională scrie modificările înapoi în HubSpot din instrumentul tău intern, precum și le citește. Pericolul este o buclă de feedback: scrierea ta înapoi declanșează exact webhook-ul care ți-a activat handler-ul, care scrie din nou, la infinit. Previno-o cu o cheie de idempotență (sari peste modificările pe care le-ai aplicat deja) și un flag de sursă (ignoră evenimentele inbound cauzate de propriul tău instrument).

const processed = new Set(); // use Redis or a unique DB constraint in production

async function writeBackToHubSpot(record) {
  // Dedup key: object id + a hash of the change we're about to apply
  const key = `${record.id}:${record.updatedHash}`;
  if (processed.has(key)) return; // already synced this exact change
  processed.add(key);

  await withRetry(() =>
    hubspot.crm.contacts.basicApi.update(record.id, {
      // Tag the source so the resulting webhook is ignored by our own receiver
      // (check for source: "internal-tool" before acting on an inbound event)
      properties: { internal_status: record.status, last_sync_source: "internal-tool" },
    })
  );
}

Modelul este mic, dar omiterea lui este modul în care o sincronizare își dublează liniștit volumul de scriere peste noapte. Odată ce datele sunt curate în ambele direcții, echipele le alimentează adesea downstream într-un pipeline AI SDR sau într-un strat de raportare. Tutorialul de integrare HubSpot al Nango este o referință solidă doar pentru Node dacă dorești o a doua perspectivă asupra sincronizării bidirecționale, deși va trebui să porți singur ideea de prevenire a buclelor.

Ar trebui să construiești asta intern sau să angajezi un partener de integrare?

Construiește intern când sincronizarea este mică, stabilă și deținută: un flux unidirecțional, câteva obiecte și un inginer care poate absorbi modificările breaking ale HubSpot de aproximativ două ori pe an. Angajează un partener când ai nevoie de sincronizare bidirecțională, modelare de obiecte personalizate sau când nimeni din echipă nu poate deține mentenanța ongoing. Factorul decisiv este rareori construcția inițială; ci cine o monitorizează peste un an.

Iată o listă de verificare onestă. Construiește-o singur dacă: direcția este unidirecțională, sincronizezi obiecte standard, ai un dezvoltator care poate găzdui un endpoint webhook și cineva va observa când un payload începe să eșueze. Tot ce este mai sus este blueprint-ul tău.

Angajează un partener dacă: ai nevoie de sincronizare bidirecțională cu prevenirea buclelor across mai multe obiecte, modelezi obiecte personalizate cu asocieri tipizate, conectezi multiple sisteme (HubSpot plus un ERP plus facturare) sau persoana care ar întreține-o este deja la capacitate maximă. HubSpot folosește versionarea API bazată pe date cu modificări breaking doar de aproximativ două ori pe an, ceea sună blând până când una aterizează în cea mai aglomerată săptămână a ta și nu există un owner. Acea coadă de mentenanță, nu primul deploy, este ceea ce scufundă liniștit integrările interne. Dacă preferi să nu deții asta, aici intervin serviciile noastre personalizate de integrare CRM.

Concluzii cheie

• Nu mai există cheie API HubSpot. Folosește un token de acces pentru aplicație privată pentru un instrument intern single-account; OAuth este doar pentru aplicații publice, multi-cont.
• Validează întotdeauna X-HubSpot-Signature-v3 înainte de a avea încredere într-un payload webhook. Reconstruiește șirul sursă cu URL-ul țintă complet.
• Respectă capul de 4 req/s pentru CRM Search și batch-uiește scrierile mari în grupuri de 100 cu backoff la 429.
• Preferă webhook-urile în locul polling-ului pentru sincronizare în timp real, iar o integrare HubSpot este o piesă dintr-o stivă mai largă de instrumente AI pentru business.

Blocat pe partea de mentenanță sau vrei o a doua pereche de ochi înainte de a lansa? Programează o consultație gratuită de integrare. Fără presiuni în niciun sens; codul de mai sus este al tău să îl rulezi indiferent.

Despre autor

Mert Batur Gurbuz este Co-Fondator al Techsy.io, unde echipa livrează agenți AI, sisteme de automatizare și pipeline-uri voice/SDR pentru clienți B2B. Studiază la Universitatea din Birmingham și scrie despre stiva de tooling LLM pe care echipa Techsy o folosește efectiv în producție. Credențiale: Co-Fondator, Techsy.io, Universitatea din Birmingham. Conectează-te pe LinkedIn.

Întrebări frecvente

Mai am nevoie de o cheie API HubSpot în 2026?

Nu. HubSpot a retras cheile API statice pe 30 noiembrie 2022, iar acestea sunt complet neacceptate. Autocomplete-ul sugerează încă „hubspot api key” din obișnuință, dar nu există nimic de preluat. Pentru un instrument intern single-account, creează o aplicație privată în Setări și folosește tokenul său de acces în schimb.

Care este diferența dintre un token de aplicație privată și OAuth pentru HubSpot?

Un token de acces pentru aplicație privată este un credencial static pentru un singur cont HubSpot, fără expirare și fără flux de reîmprospătare, ideal pentru un instrument intern. OAuth 2.0 este pentru aplicații publice, multi-cont pe care alte companii le instalează în propriile lor portaluri; tokenurile sale expiră în aproximativ șase ore și necesită un ciclu de reîmprospătare.

Care sunt limitele de rate API HubSpot în 2026?

Aplicațiile private primesc aproximativ 10 cereri pe secundă (100 la 10 secunde pe Free/Starter, 190 pe Pro/Enterprise) cu un cap zilnic de 250.000 până la 1.000.000. API-ul CRM Search este limitat separat la 4 cereri pe secundă, iar endpoint-urile batch acceptă un maxim de 100 de înregistrări per cerere.

Cum validez o semnătură webhook HubSpot?

Folosește rețeta v3: respinge cererile unde X-HubSpot-Request-Timestamp este mai vechi de cinci minute, apoi construiește un șir sursă din metodă plus URL țintă complet plus corp brut plus timestamp. Aplică HMAC-SHA256 cu secretul aplicației tale, encodează rezultatul base64 și compară-l cu X-HubSpot-Signature-v3 în timp constant.

Care SDK HubSpot ar trebui să folosesc, Node sau Python?

Ambele sunt oficiale și întreținute. Node folosește @hubspot/api-client (v14) iar Python folosește hubspot-api-client (v12). Ele expun același model de obiecte CRM v3, așa că alege whichever se potrivește stivei tale. Acest ghid livrează cod identic de autentificare și validare a semnăturii în ambele limbaje.

Cum sincronizez HubSpot cu un instrument intern personalizat în timp real?

Înregistrează o subscripție webhook în aplicația ta privată pentru obiectul și evenimentul care te interesează, apoi găzduiește un endpoint HTTPS către care HubSpot postează când apare o modificare corespunzătoare. Validează semnătura, apoi scrie modificarea în instrumentul tău intern. Folosește polling doar când nicio subscripție webhook nu acoperă ceea ce ai nevoie.

Ce este o cheie Service HubSpot și ar trebui să o folosesc?

O cheie Service este un credencial la nivel de cont, doar pentru date, pe care HubSpot l-a introdus în beta publică în februarie 2026. Este destinată joburilor server-side care ating doar date. Pentru un instrument intern standard astăzi, un token de acces pentru aplicație privată este încă implicitul mai sigur și mai bine documentat; tratează cheile Service ca beta până când sunt promovate oficial.

Pot testa o integrare HubSpot fără a atinge producția?

Da. Creează un sandbox de dezvoltator HubSpot și îndreaptă tokenul aplicației tale private către el. Domeniile (scopes), modelul de obiecte, webhook-urile și limitele de rate se comportă la fel ca în producție, astfel încât poți crea contacte de test și declanșa webhook-uri fără a lăsa înregistrări junk pe care echipa ta de vânzări să le curățe mai târziu.

Câte înregistrări poate prelua API-ul batch HubSpot odată?

Endpoint-urile batch (POST /crm/v3/objects/{objectType}/batch/create și surorile sale de update și upsert) acceptă un maxim de 100 de înregistrări per cerere. Fragmenteează payload-urile mai mari în grupuri de 100. Vechiul plafon de „10 înregistrări pentru contacte” citat încă de unele tutoriale a fost eliminat; 100 este actualul across tipuri de obiecte.

Ar trebui să construiesc asta intern sau să angajez o agenție?

Construiește intern când sincronizarea este unidirecțională, folosește obiecte standard și are un owner care poate absorbi modificările breaking ale HubSpot de două ori pe an. Angajează un partener pentru sincronizare bidirecțională, modelare obiecte personalizate sau când nimeni nu poate deține mentenanța. Primul deploy este ușor; anul de upkeep de după este costul real.