HubSpot har gjort sexton nya API:er allmänt tillgängliga och i samma utgåva satt en enda daterad deadline för allt som kom före dem. Kombinationen är mer användbar än endera halvan på egen hand. I åratal var det ärliga svaret på frågan "varför behöver den integrationen anpassad kod?" att HubSpot helt enkelt inte exponerade objektet i fråga, så någon byggde en lösning, dokumenterade den tunt och gick vidare. Den 15 september blev listan över saker som fortfarande behöver en lösning betydligt kortare, och det finns nu ett datum i kalendern som gör att det att rensa ut de gamla till finansierat arbete snarare än en god avsikt.
Ett av dessa datum passerade igår, vilket är ett bra argument för att läsa pressmeddelandet ordentligt denna vecka snarare än nästa kvartal. Ingenting i det är störande, och allt är städning som lönar sig i form av rapporteringsnoggrannhet och integrationssäkerhet.
Vad levererade HubSpot till utvecklare i september 2026?
Fall Spotlight-utvecklarversionen släpptes den 15 september, dagen innan UNBOUND öppnade i Boston, och det är den mest omfattande utvidgningen av HubSpots API-yta på flera år. Developer Platform 2026.09 nådde allmän tillgänglighet som plattformens andra datumbaserade release, med ett arton månaders supportfönster som anger exakt hur länge den version du bygger på kommer att underhållas. Den förutsägbarheten är en tyst men verklig uppgradering av numrerad versionshantering, där slutet på supporten alltid var ett beslut.
Sexton API:er har blivit allmänt tillgängliga, och flera av dem täcker luckor som HubSpots kunder har arbetat med länge. Conversations API ger programmatisk åtkomst till den delade inkorgen och helpdesk. Prisböcker och betalningslänkar öppnar Commerce Hub för professionella och företagskonton, med betalningslänkar som nu kan bära dynamiska varukorgar med flera artiklar. Ett Pipeline Rules API täcker vad HubSpot själva beskrev som ett långvarigt paritetsgap. Prognoser ger skrivskyddad åtkomst till inskickade prognoser, Teams tillåter teamskapande och medlemshantering utanför gränssnittet, Object Tags applicerar färgade etiketter på poster automatiskt och e-postmallar kommer med användarbehörighet. Ytterligare åtta API:er har gått in i offentlig beta, bland annat lead scoring, kontrakt, marknadsföringsformulär och automatiserade arbetsflöden.
Utöver dessa har Connected Apps-upplevelsen byggts om kring flikar, formellt appägarskap som kan omtilldelas när någon slutar, och en aktivitetslogg som täcker installationer, behörighetshändelser och ägarändringar. HubSpot MCP-servern har nu tillgång till anpassade objekt, Breeze Assistant kan vägleda agentkonfiguration i offentlig beta, och schemalagda prompter låter återkommande assistentuppgifter köras enligt ett schema.
Vad är teknisk skuld i CRM, och varför är en publicerad deadline bra?
Teknisk skuld i CRM är den ackumulerade kostnaden för beslut som var vettiga vid den tidpunkten och som aldrig omprövades: anpassad kod skriven eftersom en standardfunktion ännu inte existerade, integrationer byggda mot en API-version som sedan dess har ersatts, arbetsflöden som ingen har granskat sedan personen som byggde dem slutade, och fält som skapats för en kampanj som avslutades för tre år sedan. Det är sällan brådskande och nästan aldrig synligt för de personer som godkänner budgetar, vilket är just därför det ackumuleras. Skulden är inte själva koden. Det är det faktum att ingen med säkerhet kan säga vad koden gör, så varje nytt projekt måste arbeta runt den snarare än genom den.
Det är här ett publicerat solnedgångsdatum förtjänar sin plats. Förfrågningar om att modernisera integrationer förlorar till förfrågningar som genererar intäkter, varje gång, eftersom den första beskrivs som städning och den andra som tillväxt. Ett leverantörsdatum ändrar den konversationen på en rad. Från och med september 2027 flyttas slutpunkter på /v1/, /v2/ och /v3/-banorna till statusen "ostöds inte", vilket HubSpot definierar som inga ytterligare buggfixar, tillförlitlighetsförbättringar eller säkerhetsuppdateringar. Det sista alternativet är det som får en budget godkänd. Version 4 körs enligt sin egen tidigare tidslinje och stöds inte längre den 30 mars 2027, och appar som byggts på Projects 2025.2-ramverket eller äldre måste nå 2026.09 senast i mars 2027. HubSpots riktlinjer är att migrera direkt till datumbaserad versionshantering snarare än att gå igenom de numrerade versionerna.
Läst i den ordningen är detta en tolvmånadersperiod med två mellanliggande punkter inuti, vilket är betydligt mer planeringsutrymme än vad de flesta plattformsförändringar erbjuder. Två av appens deadlines ligger närmare varandra. Skapandet av äldre privata appar stängdes för nya HubSpot-konton den 28 september och stänger för befintliga konton den 26 oktober, så alla interna verktyg som någon planerat att använda på det gamla sättet har ungefär fyra veckor kvar. Offentliga appar på pre-Projects-arkitekturen, vilket betyder allt som skapats före den 23 juni 2026, flyttade till statusen "ostöds inte" den 15 september och riskerar att Marketplace tas bort från september 2027 om de inte har migrerat. För de flesta B2B-intäktsteam är den praktiska tolkningen dock enklare och mer uppmuntrande: ingenting går sönder den här månaden, och du har ett år på dig att arbeta igenom en lista som du förmodligen har tänkt skriva ändå.
Hur bygger man upp ett integrationsinventarium som är värt att ha?
En CRM-förstudie är en kort, strukturerad bedömning som utförs innan ett projekts omfattning fastställs, vanligtvis två till sex veckor, för att fastställa vad som faktiskt finns på plats snarare än vad dokumentationen påstår. Den inventerar integrationer, anpassad kod, automatisering, datakvalitet och de affärsprocesser som var och en stöder, och mappar sedan varje punkt till det resultat den tjänar och de människor som är beroende av den. Resultatet är en prioriterad bild av vad som ska behållas, vad som ska ersättas och vad som ska tas bort, med anslagsuppskattningar. Dess värde ligger i att den omvandlar en vag känsla av att systemet har blivit komplicerat till en kostnadsberäknad uppsättning beslut som en styrgrupp kan fatta på ett enda möte.
Tillämpad på den här versionen besvarar en förstudie tre frågor. Vilka av era integrationer anropar versionerade slutpunkter, och vilka av dessa anrop har nu en datumbaserad motsvarighet? Vilka av era specialbyggda lösningar ersätts helt av en av de sexton nya tillgängliga API:erna, så migreringen är en borttagning snarare än en omskrivning? Och vilka integrationer kan ingen i organisationen förklara, vilka vanligtvis är den mest intressanta kategorin och tillförlitligt den som ger besparingar.
Den tredje frågan är anledningen till att göra detta arbete oavsett deadline. Team som kör inventeringen korrekt hittar rutinmässigt anslutningar som fortfarande förbrukar licenser och API-anrop för en process som slutade köras för månader sedan, och att stänga av dem är det sällsynta tekniska arbetet som syns i siffrorna för samma kvartal.
Vad är Shadow AI, och var ändrar servicenycklar bilden?
Skugg-AI är användningen av AI-verktyg och AI-driven automatisering inom en organisation utan kunskap, godkännande eller tillsyn från de personer som ansvarar för datastyrning. Det börjar vanligtvis bra: ett team med ett genuint problem hittar ett verktyg som löser det och kopplar det till de system som innehåller den data det behöver. Risken är inte entusiasmen, det är osynligheten, eftersom ingen kan säkra, granska eller förbättra en anslutning de inte vet existerar. Det effektiva svaret är inte förbud, vilket tenderar att skjuta aktiviteten ytterligare ur sikte, utan en sanktionerad väg som är lättare att använda än den icke-sanktionerade, med begränsade behörigheter och central insyn inbyggd från början.
Servicenycklar, nu i offentlig betaversion, är just den typen av sanktionerad väg. HubSpot positionerar dem som ersättare för äldre privata appar i lättviktsintegrationer, interna verktyg och, framför allt, integrationer med AI-agenter, med striktare säkerhetsstandarder och korrekt behörighetsomfång. Appar på användarnivå kommer tillsammans med dem. Kombinera det med den nya aktivitetsloggen för anslutna appar och namngivet, omtilldelbart appägande, och resultatet är en plattform där en liten integration byggd av någon inom marknadsföring är synlig, tillskrivbar och begränsad som standard.
Det är en verklig förbättring jämfört med det tidigare arrangemanget, där en privat app-token med bred åtkomst kunde ligga kvar i ett kalkylblad på obestämd tid. Det passar också bra ihop med HubSpots tidigare drag att tillämpa valideringsregler vid API-gränsen, vilket vi tog upp i Augusti. Sammantaget är riktningen tydlig och välkommen: styrningen flyttar sig från gränssnittet till den plats där data faktiskt kommer in i systemet.
Hur man integrerar CRM med ERP när API-ytan ständigt rör sig
Att integrera CRM med ERP fungerar bäst genom ett definierat mellanlager snarare än ett nätverk av punkt-till-punkt-kopplingar. Upprätta ett enda system för poster för varje objekt, vanligtvis konton och produkter i ERP:n och möjligheter och aktiviteter i CRM:et, och flytta sedan data genom en integrationsplattform som samlar mappningen, transformationsreglerna och felhanteringen på ett ställe. Synkronisera affärshändelser snarare än enligt ett fast schema där volymen tillåter det, logga varje misslyckad post så att undantag är synliga snarare än tysta, och versionsskriv mappningen tillsammans med koden som förbrukar den. Mönstret kostar något mer att bygga och betydligt mindre att underhålla, eftersom ett plattformsbyte då påverkar en koppling istället för femton skript.
Det argumentet är lätt att framföra abstrakt och svårt att finansiera i praktiken, vilket är just därför en daterad API-nedgång är bra. Organisationer som kör punkt-till-punkt-integrationer står inför en migrering i varje skript som anropar en versionerad slutpunkt. Organisationer som kör ett mellanlager ändrar kopplingen en gång. Tillverkningsklienter med CPQ och citerar logik mellan de två systemen känner detta starkast, eftersom prissättningsvägen är den som ingen vill röra två gånger. Om de kommande tolv månaderna producerar en arkitektonisk förbättring är det den som är värd att välja.
Hur mäter man avkastningen på integrationsmodernisering?
Mät CRM-ROI på operativa mätvärden som förändras före intäkterna. De användbara mätvärdena inkluderar andelen integrationskörningar som slutförs utan manuell intervention, tiden från en begäran om ett nytt dataflöde tills det flödet är live, antalet poster som kräver manuell korrigering varje vecka, licens- och API-förbrukning på integrationer som inte längre tjänar en aktiv process, och andelen rapportering som hämtas från en enda överenskommen källa. Var och en är tillgänglig i veckor snarare än kvartal, var och en kan hänföras till en specifik förändring, och tillsammans förutspår de de intäktsresultat som följer. Baslinjesätt dem innan arbetet påbörjas, eftersom baslinjen är det som gör förbättringen argumenterbar på styrelsenivå.
I just den här versionen är det ovanligt lätt att namnge returerna i förväg. Varje lösning som ersätts av ett av de sexton nya API:erna är kod som du slutar underhålla. Varje äldre privat app som konverteras till en scoped service key är en åtkomstväg som du äntligen kan granska. Varje pensionerad integration är återvunna licenskostnader. Och efter att ha gjort inventeringen en gång blir nästa plattformsbyte, från vilken leverantör som helst, en halvdagsbedömning snarare än ett projekt.
Siroccos perspektiv
Vi arbetar med Salesforce, HubSpot och Microsoft Dynamics 365, och samma mönster har varit synligt för alla tre i år. Salesforce pensionerar API-versioner vid en publicerad releasetid. Microsoft gick över till kontinuerlig leverans med daterade servicemeddelanden. HubSpot har nu infört datumbaserad versionshantering med supportfönster som du kan läsa på en sida. Leverantörer gör sina underhållsåtaganden tydliga, och det är helt enkelt bra för köpare, eftersom tydliga åtaganden är det som gör att en färdplan kan planeras snarare än att reageras på.
Det är i arbete som detta som en oberoende CRM-partner förtjänar sin plats. Eftersom vi inte har någon licenskvot på någon plattform kommer våra rekommendationer om vad som ska migreras, vad som ska pensioneras och vad som ska lämnas orörda från kundens process snarare än från en leverantörs roadmap. Vi har kört samma integrationsinventering på alla tre plattformar, så vi kan avgöra vilka resultat som är genuint plattformsspecifika och vilka helt enkelt är hur integrationer åldras överallt. Och när det ärliga svaret är att en befintlig installation är i gott skick och att deadline bara kräver två veckor av fokuserat arbete, är vi fria att säga det.
Vårt råd för den kommande månaden är oglamoröst och ger hög avkastning: lägg en vecka på att bygga upp inventeringen, ta de snabba vinsterna där ett nytt API ersätter anpassad kod helt och hållet, och schemalägg de återstående migreringarna under de tolv månader ni har fått. Team som gör detta kommer att spendera 2027 med att bygga på en plattform de förstår, med en mycket kortare lista över saker som ingen kan förklara. Det är en stark position att befinna sig i, och den här releasen är en vältajmad inbjudan att komma dit.
Om du vill ha en andra granskning av lagret, eller om du vill se vilka av de sexton nya tillgängliga API:erna som faktiskt ersätter något du underhåller idag, Boka en konsultation med vårt team.
Kontakta oss
Om ni funderar ut vilka av era HubSpot-integrationer som fortfarande anropar versionerade slutpunkter, och vilka som ett nyligen tillgängligt API nu ersätter helt, berätta för oss var ni befinner er så hjälper vi er att bygga upp inventeringen.
