HubSpot has opened sixteen new APIs to general availability and, in the same release, put a single dated deadline on everything that came before them. The combination is more useful than either half on its own. For years the honest answer to the question “why does that integration need custom code?” was that HubSpot simply did not expose the object in question, so somebody built a workaround, documented it thinly and moved on. On 15 September the list of things that still need a workaround got considerably shorter, and there is now a date in the calendar that turns clearing out the old ones into funded work rather than a good intention.
One of those dates passed yesterday, which is a fair argument for reading the release properly this week rather than next quarter. Nothing in it is disruptive, and all of it is housekeeping that pays for itself in reporting accuracy and integration reliability.
What did HubSpot ship for developers in September 2026?
The Fall Spotlight developer release landed on 15 September, the day before UNBOUND opened in Boston, and it is the most substantial widening of HubSpot’s API surface in several years. Developer Platform 2026.09 reached general availability as the platform’s second date-based release, carrying an eighteen month support window that tells you precisely how long the version you build on will be maintained. That predictability is a quiet but real upgrade on numbered versioning, where the end of support was always a judgement call.
Sixteen APIs moved to general availability, and several of them close gaps that HubSpot customers have been engineering around for a long time. The Conversations API gives programmatic access to the shared inbox and Help Desk. Price Books and Payment Links open up Commerce Hub for professional and enterprise accounts, with payment links now able to carry dynamic multi-item carts. A Pipeline Rules API closes what HubSpot itself described as a long-standing parity gap. Forecasts exposes read-only access to submitted forecasts, Teams allows team creation and membership management from outside the interface, Object Tags applies coloured labels to records automatically, and Email Templates arrives with user-level authorisation. Eight further APIs entered public beta, among them lead scoring, contracts, marketing forms and automation workflows.
Alongside those, the Connected Apps experience was rebuilt around tabbed settings, formal app ownership that can be reassigned when somebody leaves, and an activity log covering installations, permission events and ownership changes. The HubSpot MCP server now reaches custom objects, Breeze Assistant can guide agent configuration in public beta, and scheduled prompts let recurring assistant tasks run on a timetable.
What is CRM technical debt, and why does a published deadline help?
CRM technical debt is the accumulated cost of decisions that made sense at the time and were never revisited: custom code written because a standard feature did not exist yet, integrations built against an API version that has since been superseded, workflows nobody has audited since the person who built them left, and fields created for a campaign that ended three years ago. It is rarely urgent and almost never visible to the people who approve budgets, which is precisely why it accumulates. The debt is not the code itself. It is the fact that nobody can say with confidence what the code does, so every new project has to work around it rather than through it.
This is where a published sunset date earns its keep. Requests to modernise integrations lose to requests that generate revenue, every time, because the first gets described as tidying and the second as growth. A vendor date changes that conversation in one line. From September 2027, endpoints on the /v1/, /v2/ and /v3/ paths move to unsupported status, which HubSpot defines as no further bug fixes, reliability improvements or security updates. That last item is the one that gets a budget approved. Version 4 runs on its own earlier timeline and goes unsupported on 30 March 2027, and apps built on the Projects 2025.2 framework or older need to reach 2026.09 by March 2027. HubSpot’s guidance is to migrate straight to date-based versioning rather than stepping through the numbered versions.
Read in that order, this is a twelve month runway with two staging posts inside it, which is considerably more planning room than most platform changes offer. Two of the app deadlines sit closer. Legacy private app creation closed for new HubSpot accounts on 28 September and closes for existing accounts on 26 October, so any internal tool somebody planned to stand up the old way has about four weeks left. Public apps on the pre-Projects architecture, meaning anything created before 23 June 2026, moved to unsupported status on 15 September and risk Marketplace delisting from September 2027 if they have not migrated. For most B2B revenue teams, though, the practical reading is simpler and more encouraging: nothing breaks this month, and you have a year to work through a list you have probably been meaning to write anyway.
How do you build an integration inventory worth having?
A CRM pre-study is a short, structured assessment carried out before a project is scoped, usually two to six weeks, that establishes what is actually in place rather than what the documentation claims. It inventories integrations, custom code, automation, data quality and the business processes each one supports, then maps every item to the outcome it serves and the people who depend on it. The output is a prioritised picture of what to keep, what to replace and what to retire, with effort estimates attached. Its value is that it converts a vague sense that the system has grown complicated into a costed set of decisions a steering group can take in a single meeting.
Applied to this release, a pre-study answers three questions. Which of your integrations call versioned endpoints, and which of those calls now have a date-based equivalent? Which of your custom-built workarounds are replaced outright by one of the sixteen newly available APIs, so the migration is a deletion rather than a rewrite? And which integrations can nobody in the organisation explain, which is usually the most interesting category and reliably the one that turns up savings.
That third question is the reason to do this work regardless of any deadline. Teams that run the inventory properly routinely find connections still consuming licences and API calls on behalf of a process that stopped running months ago, and switching those off is the rare piece of technical work that shows up in the same quarter’s numbers.
What is Shadow AI, and where do service keys change the picture?
Shadow AI is the use of AI tools and AI-driven automation inside an organisation without the knowledge, approval or oversight of the people accountable for data governance. It usually starts well: a team with a genuine problem finds a tool that solves it and connects it to the systems holding the data it needs. The risk is not the enthusiasm, it is the invisibility, because nobody can secure, audit or improve a connection they do not know exists. The effective response is not prohibition, which tends to push the activity further out of sight, but a sanctioned path that is easier to use than the unsanctioned one, with scoped permissions and central visibility built in from the start.
Service keys, now in public beta, are precisely that sort of sanctioned path. HubSpot positions them as the replacement for legacy private apps in lightweight integrations, internal tools and, notably, AI agent integrations, with tighter security defaults and proper permission scoping. User-level apps arrive alongside them. Combine that with the new Connected Apps activity log and named, reassignable app ownership, and the result is a platform where a small integration built by somebody in marketing is visible, attributable and constrained by default.
That is a real improvement on the previous arrangement, where a private app token with broad access could sit in a spreadsheet indefinitely. It also fits neatly with HubSpot’s earlier move to enforce validation rules at the API boundary, which we covered in August. Taken together, the direction is clear and welcome: governance is moving out of the interface and into the place where data actually enters the system.
How to integrate CRM with ERP when the API surface keeps moving
Integrating CRM with ERP works best through a defined middle layer rather than a web of point-to-point connections. Establish a single system of record for each object, typically accounts and products in the ERP and opportunities and activities in the CRM, then move data through an integration platform that holds the mapping, the transformation rules and the error handling in one place. Synchronise on business events rather than on a fixed timetable where the volume allows it, log every failed record so exceptions are visible rather than silent, and version the mapping alongside the code that consumes it. The pattern costs slightly more to build and considerably less to maintain, because a platform change then affects one connector instead of fifteen scripts.
That argument is easy to make in the abstract and hard to fund in practice, which is exactly why a dated API sunset is helpful. Organisations running point-to-point integrations face a migration in every script that calls a versioned endpoint. Organisations running a middle layer change the connector once. Manufacturing clients with CPQ and quoting logic between the two systems feel this most sharply, because the pricing path is the one nobody wants to touch twice. If the next twelve months produce one architectural improvement, this is the one worth choosing.
How do you measure the return on integration modernisation?
Measure CRM ROI on operational metrics that move before revenue does. The useful ones include the proportion of integration runs that complete without manual intervention, the time from a request for a new data flow to that flow being live, the number of records requiring manual correction each week, licence and API consumption on integrations that no longer serve an active process, and the share of reporting that pulls from a single agreed source. Each is available in weeks rather than quarters, each is attributable to a specific change, and together they predict the revenue outcomes that follow. Baseline them before the work begins, because the baseline is what makes the improvement arguable at board level.
On this particular release the returns are unusually easy to name in advance. Every workaround replaced by one of the sixteen new APIs is code you stop maintaining. Every legacy private app converted to a scoped service key is an access path you can finally audit. Every retired integration is licence spend recovered. And having done the inventory once, the next platform change, from any vendor, becomes a half-day assessment rather than a project.
The Sirocco perspective
We work across Salesforce, HubSpot and Microsoft Dynamics 365, and the same pattern has been visible on all three this year. Salesforce retires API versions on a published release clock. Microsoft moved to continuous delivery with dated service notices. HubSpot has now adopted date-based versioning with support windows you can read off a page. Vendors are making their maintenance commitments legible, and that is straightforwardly good for buyers, because legible commitments are what allow a roadmap to be planned rather than reacted to.
Work like this is where an independent CRM partner earns its place. Because we carry no licence quota on any platform, our recommendation on what to migrate, what to retire and what to leave alone comes from the client’s process rather than from a vendor roadmap. We have run the same integration inventory on all three platforms, so we can tell which findings are genuinely platform-specific and which are simply how integrations age everywhere. And when the honest answer is that an existing setup is in good shape and the deadline needs only a fortnight of focused work, we are free to say so.
Our advice for the coming month is unglamorous and high-yield: spend a week building the inventory, take the quick wins where a new API replaces custom code outright, and schedule the remaining migrations across the twelve months you have been given. Teams that do this will spend 2027 building on a platform they understand, with a much shorter list of things nobody can explain. That is a strong position to be in, and this release is a well-timed invitation to get there.
If you would like a second pair of eyes on the inventory, or on which of the sixteen newly available APIs actually replaces something you are maintaining today, schedule a consultation with our team.
Get in Touch
If you are working out which of your HubSpot integrations still call versioned endpoints, and which ones a newly available API now replaces outright, tell us where you are and we will help you build the inventory.
