Hvad er Hub ID i HubSpot?

Sådan fungerer Hub ID i HubSpot

Et Hub ID er et heltal, som HubSpot tildeler ved oprettelsen af en konto. Det er unikt på tværs af hele platformen, det følger kontoen resten af dens levetid, og det kan hverken vælges, genbruges eller flyttes til en anden konto. Alt, hvad der herunder beskrives som kontospecifikt, hænger på netop det tal.

Du finder det to steder i grænsefladen. Klikker du på kontonavnet øverst til højre, står Hub ID'et under navnet, og det samme tal står midt i URL'en på stort set enhver side i portalen. HubSpots vejledning i at håndtere flere konti beskriver også kontoskiftet: menuen viser de konti, din e-mail allerede er oprettet som bruger på, og du kan ikke skifte til en konto, nogen ikke har givet dig adgang til.

I API'et hedder det portalId, og det er her, tallet får teknisk betydning. Kaldet til account-info returnerer portalId sammen med portalName, accountType, timeZone, companyCurrency, additionalCurrencies, uiDomain og dataHostingLocation. HubSpots API-reference for kontooplysninger oplyser, at kaldet kun kræver oauth-scopet og virker på alle produkter helt ned til gratisniveauet, hvilket gør det til den billigste måde at få en integration til selv at fortælle, hvilken konto den er forbundet til.

accountType afslører, hvilken slags konto du står i. Feltet kan have værdierne STANDARD, DEVELOPER_TEST, SANDBOX og APP_DEVELOPER. Netop derfor har hver af de kontotyper sit eget Hub ID: en sandkasse er en selvstændig konto med sit eget tal, ikke et tilstandsskifte i produktionskontoen. Det er også derfor, et private app-token fra produktionen ikke virker i sandkassen: tokenet skal oprettes inde i den konto, det skal bruges i. Det er den enkeltdetalje, der oftest misforstås, og den forklarer hovedparten af de integrationsfejl, vi bliver kaldt ud til.

OAuth bruger det samme tal til at afgøre, hvilken konto et token giver adgang til. Slår du et access token op, får du hub_id tilbage sammen med app_id og user_id, og de tre skal holdes adskilt: hub_id er kontoen, app_id er den app, tokenet blev udstedt til, og user_id er personen, der godkendte den. HubSpots dokumentation om OAuth-tokens viser opslaget, og det hører hjemme i enhver integration, der kan forbindes til mere end én konto.

Tracking-scriptet bærer også Hub ID'et. Det er derfor, et website kun kan sende data til den konto, scriptet er hentet fra, og det er derfor, en kopieret side fra et andet projekt pludselig kan fodre den forkerte portal med besøgsdata. Skifter I konto, skal scriptet udskiftes overalt, også i de skabeloner og landingssider, ingen har rørt i to år.

Udviklerkonti og testkonti hører til samme familie, men med skarpe grænser. HubSpots oversigt over kontotyper beskriver, at du kan have op til ti developer test accounts pr. standardkonto, at de er gratis, og at de udløber efter 90 dage uden API-aktivitet. De har desuden loft på indholdet: 25 websitesider, 25 landingssider og én blog med 100 indlæg, og workflows kan tilmelde højst 100.000 poster om dagen.

Standardsandkassen er en anden sag og kræver Enterprise. Den kopierer kontoens opsætning, og du kan vælge at tage de 5.000 senest opdaterede kontakter med sammen med op til 100 tilknyttede deals, virksomheder og tickets pr. kontakt. Der kan udrulles op til 300 ændringer pr. deployment til produktion, og du kan importere op til 200.000 poster pr. objekttype manuelt.

Datalokation hænger fast på kontoen og dermed på Hub ID'et. Det er derfor, dataHostingLocation overhovedet er et felt i API'et: to konti i samme virksomhed kan ligge i hver sin region, og feltet er den eneste maskinlæsbare måde at se hvilken.

Der er til gengæld ingen hierarki mellem Hub ID'er. HubSpot har ikke et koncern-id, der binder flere konti sammen, ingen fælles brugeradministration på tværs og ingen rapportering, der lægger to konti oven på hinanden. Skal to konti dele data, skal de forbindes med en integration på lige fod med et hvilket som helst andet eksternt system, og det er netop den mangel, der driver valget mellem én og flere konti.

Vi hjælper danske B2B-virksomheder med at lægge kontostrukturen rigtigt fra start: om I skal have ét Hub ID eller flere, hvordan brands, teams og adgangsstyring skal skæres, og hvordan integrationer gemmer og validerer hub_id, så data ikke ender i den forkerte portal. Står I midt i et opkøb eller en oprydning efter et, så send os en oversigt over jeres konti, så gennemgår vi modellerne og konsekvenserne med jer.

Hvad danske B2B-teams bruger Hub ID til

Hub ID er sjældent noget, nogen sætter sig for at arbejde med. Det dukker op, når en anden opgave kræver, at man kan sige præcis hvilken konto, der tales om, og så er det som regel de her situationer.

Supportsager hos HubSpot
Supporten spørger om Hub ID'et i stort set enhver sag, fordi navnet på virksomheden ikke er entydigt. Har I flere konti, sparer I en hel svarrunde ved at sende tallet med i første besked. Skriv det ind i jeres interne dokumentation i stedet for at lede i URL'en hver gang.

Bureauer og partnere med flere kunder
Arbejder I med flere portaler i samme browser, er Hub ID'et det eneste sikre tjek på, at I er det rigtige sted. Kontonavne ligner ofte hinanden, især når en kunde har både en produktionskonto og en sandkasse. Vi har set en e-mailudsendelse ramme den forkerte database, fordi de to konti hed næsten det samme.

Integrationer til e-conomic og Business Central
En integration, der kan forbindes til mere end én konto, skal gemme hub_id sammen med tokenet og validere det ved hvert kald. Ellers opdager I først, at data er skrevet til den forkerte portal, når økonomiafdelingen spørger, hvorfor fakturaerne står på en kunde, der ikke findes. Det er ti linjers kode at bygge ind og dyrt at undvære.

Fejlfinding i webhooks og logfiler
Webhook-payloads indeholder kontoens id, og det gør det muligt at filtrere logs pr. konto, når noget driller. Uden det tjek ender man med at lede efter en fejl i produktionen, der i virkeligheden stammer fra en testkonto, nogen glemte at koble fra.

Deployment fra sandkasse til produktion
Fordi sandkassen har sit eget Hub ID, skal alt, der refererer til en konto, være en variabel og aldrig en fast værdi i koden. Det gælder tracking-scriptet, API-kald og de URL'er, der peger ind i portalen. Lav tjekket til en fast del af jeres deployment, så det ikke afhænger af, at nogen husker det.

Dokumentation til databehandleraftalen
Skal I kunne dokumentere, hvor persondata ligger, er kontoen den enhed, spørgsmålet handler om, og dataHostingLocation svarer på det direkte. For virksomheder i regulerede brancher er det hurtigere at trække svaret fra API'et end at lede i aftalepapirer.

Beslutningen om én eller flere konti
Køber I et selskab, står I med to Hub ID'er og skal beslutte, om de skal blive ved med at være to. Svaret afhænger af, om de to forretninger deler kunder og processer eller reelt ikke har noget med hinanden at gøre. Det er en forretningsbeslutning før en teknisk, og den er svær at lave om bagefter.

Adgangsstyring ved opsigelser
Brugeradgang gives pr. konto, så en medarbejder, der stopper, skal fjernes i hver enkelt portal. Har I fem Hub ID'er, er der fem steder at rydde op, og der findes ingen central liste, der viser det for jer. Den slags hører til på offboarding-tjeklisten.

Fællestrækket er, at Hub ID'et er billigt at holde styr på og dyrt at tage fejl af. Skriv jeres konti og deres id'er ned ét sted, og gør det til en vane at læse tallet i URL'en, inden nogen trykker send på noget, der ikke kan trækkes tilbage.

Alternativer, priser og begrænsninger

Det dyre spørgsmål er, hvor mange Hub ID'er I skal have. Der er reelt tre modeller, og de koster vidt forskellige penge. Her er de, med de priser vi kunne verificere.

Én konto med Brands
Brands, der tidligere hed business units, lader jer køre flere mærker i den samme konto. HubSpots dokumentation om Brands er tydelig på det afgørende punkt: alle brands ligger i én konto og deler det samme Hub ID, hvert brand får sit eget tracking-script, og kun super admins kan oprette dem. Funktionen er et tilkøb til Marketing Hub Enterprise, hvor ét brand følger med hvert køb af tilkøbet, og I kan komme op på 100 brands ved at købe flere.

Flere separate konti
Den anden model er at give hver forretning sin egen konto og dermed sit eget Hub ID. Det giver fuldstændig adskillelse af data, brugere og abonnementer, hvilket er det rigtige, når to selskaber ikke deler kunder. Prisen er, at I betaler et helt abonnement pr. konto, og at der ikke findes rapportering på tværs. Alt, der skal deles, skal bygges som en integration.

Teams og partitionering i én konto
Skal I bare holde to salgsafdelinger adskilt, er svaret ofte hverken Brands eller flere konti. Teams og adgangsstyring på Enterprise kan skjule hinandens poster inden for samme Hub ID, og det koster ikke ekstra oven i abonnementet. Det er den model, vi oftest ender med at anbefale danske mellemstore virksomheder.

Salesforce og Dynamics 365
Andre platforme løser det samme med Org ID hos Salesforce og miljø-id hos Dynamics 365, og begge har en tydeligere understøttelse af flere miljøer under samme aftale end HubSpot har. Har I et reelt koncernbehov med mange selvstændige enheder, der alligevel skal rapportere samlet, er det en af de få steder, hvor arkitekturen taler imod HubSpot.

HubSpot vinder på, at én konto er enkel at drive, og at Brands løser det almindelige tilfælde med flere mærker uden at fordoble administrationen. HubSpot taber på, at der ikke findes noget lag over kontoen: ingen samlet brugeradministration, ingen rapportering på tværs af Hub ID'er og ingen måde at flytte historik fra én konto til en anden uden et egentligt migreringsprojekt. Har I mere end tre eller fire konti, mærker I den mangel hver måned.

På prissiden er Brands-vejen den dyre. Tilkøbet forudsætter Marketing Hub Enterprise, som pr. 14. september 2026 stod til 3.600 USD om måneden på HubSpots prisside for Marketing Hub, inklusive fem Core Seats og 10.000 marketing contacts, med ekstra seats til 75 USD. Til sammenligning kostede Marketing Hub Professional 800 USD om måneden med tre seats og 2.000 marketing contacts. Begge tal er i USD og uden den obligatoriske onboarding, der samme dag stod til 7.000 USD for Enterprise og 3.000 USD for Professional.

Regnestykket mellem de to modeller er derfor sjældent tæt. Har I to brands, der begge kan nøjes med Professional, er to konti billigere end én Enterprise-konto med tilkøb. Er svaret omvendt, at I alligevel skal bruge Enterprise til andet, følger Brands med som et forholdsvis billigt tilkøb oven på en beslutning, I havde truffet alligevel.

Sandkasser er et tredje sted, Hub ID'er opstår. De koster ikke ekstra ud over abonnementet, til gengæld kræver de det rigtige tier. HubSpots vejledning til standardsandkassen gør den til en Enterprise-funktion på tværs af alle Hubs. Har I Professional og har brug for at teste mod et separat Hub ID, er en gratis developer test account det, der er tilbage, med de indholdsgrænser og de 90 dages udløb, der følger med.

Kend de hårde begrænsninger, før I lægger en kontostruktur. Et Hub ID kan ikke ændres, ikke flyttes og ikke slås sammen med et andet, og der findes ingen understøttet vej til at flette to konti. En sammenlægning er i praksis en eksport fra den ene konto og en import til den anden, hvor aktivitetshistorik, e-mailstatistik og attribution ikke følger med.

Dertil kommer, at brugere, abonnementer og integrationer er kontospecifikke hele vejen igennem. En integration, der er godkendt i én konto, skal godkendes igen i den næste, og en app, der tæller mod en kvote, tæller pr. konto. Det er sjældent et problem med to konti og altid et problem med ti.

For danske virksomheder er datalokation den EU-vinkel, der knytter sig direkte til kontoen. HubSpots oversigt over datacentre nævner en EU-region ved siden af Canada, Australien og to amerikanske regioner, og nye kunder placeres efter IP-geolokation ved oprettelsen, mens gratiskonti som udgangspunkt havner i USA. Eksisterende betalende kunder kan migrere uden ekstra betaling via kontoindstillingerne, og fordi valget sidder på kontoen, kan to Hub ID'er i samme koncern sagtens ligge i hver sin region uden at nogen har besluttet det.

Det er også grunden til at tjekke dataHostingLocation, inden I skriver under på en databehandleraftale, der lover EU-hosting. Er kontoen oprettet af en kollega på ferie i USA, ligger den amerikansk, og det opdager man typisk først, når nogen spørger.

Endelig er der tilfældet, hvor hele diskussionen er spildt. Har I ét brand, ét land og under tyve brugere, er svaret én konto, og så er Hub ID blot et tal, I skriver ned til supportsager. Først når to forretninger har hver sin kundebase, hver sit website og hver sin salgsproces, bliver kontostrukturen en beslutning, der er værd at bruge tid på. Skal I have hjælp til at vurdere, hvilken vej der passer til jeres opsætning, kan I læse mere om vores arbejde med HubSpot og om, hvordan private apps og OAuth hænger sammen med kontoen.