Somewhere in your HubSpot portal there is probably a small integration nobody remembers building. It pushes trial signups from your product into the CRM, or syncs invoices, or posts new deals to Slack. It has worked quietly for years. HubSpot has now put an end date on the technology it most likely runs on.
At Fall Spotlight on September 15, 2026, HubSpot announced that its older API versions and its older app models become unsupported in September 2027. That gives every company with custom HubSpot integrations a 12-month window. This is a developer announcement, but the decision it forces is a budget decision, so it belongs on a founder’s or a sales leader’s desk.
What changed in the HubSpot legacy API announcement
HubSpot’s developer changelog lists three changes that share one enforcement date, September 2027:
- API versions v1 to v3 become unsupported. HubSpot stops shipping bug fixes, reliability improvements and security updates for them. Support for v4 ends earlier, on March 30, 2027, under a timeline HubSpot announced before. The replacement is what HubSpot calls date-based versioning, and HubSpot advises migrating straight to it rather than stepping through v3 or v4.
- Legacy public apps become unsupported. These are Marketplace apps built on the older app architecture. Vendors that do not migrate risk losing certification or being delisted.
- Legacy private apps must migrate. Private apps are the custom integrations built inside your own portal. Those built on the older model need to move to the newer Projects-based model by September 2027.
One date is much closer. HubSpot disables the creation of new legacy private apps on September 28, 2026 for new accounts and on October 26, 2026 for existing accounts. For new lightweight integrations HubSpot now recommends Service Keys instead. The non-breaking news from the same release is in the Fall Spotlight 2026 developer rollup.
Who this matters for
If your company uses HubSpot only with Marketplace apps from large vendors, your exposure is small. The vendors carry the migration work. Your job is to ask the two or three vendors you depend on whether they are on track.
It matters a lot more if any of these are true:
- A developer, agency or former employee once built a custom integration between HubSpot and your product, billing system or data warehouse.
- You are a SaaS company that pushes product usage, trials or subscription data into HubSpot. This is almost always a private app calling v3 endpoints.
- You run automation tools or scripts that use a private app token.
In most SaaS portals we open, at least one of these exists, and quite often the person who built it has left.
What to check in your portal
- Ask your admin to open Development in the HubSpot left menu and go to Legacy Apps. We checked this in a live portal: HubSpot has already moved all existing private apps onto this page and labels them as ready for migration.
- For every app listed, write down three things: what it does, who built it, and who owns it today. An app with no owner is your first risk.
- Open Development, then Migrations. HubSpot says its developer home now flags apps that call APIs becoming unsupported. The check looks at real API calls, not source code, so an integration that runs rarely may take a while to show up.
- List the Marketplace apps your revenue process depends on and ask each vendor for their migration plan in writing.
- If you planned to build a new integration this quarter, tell whoever builds it to use the current model from day one. After October 26 the old one is no longer an option for existing accounts anyway.
Our take
Twelve months sounds generous. It is not, because this work competes with everything else on a roadmap and has no visible upside. Nothing gets better for your sales team when an integration is migrated. It only keeps working. That is exactly the kind of task that slides until the month before the deadline.
Two things are worth being honest about. First, “unsupported” does not mean everything switches off on one day. It means HubSpot stops fixing those versions, including security fixes, and your integration can break without notice from then on. For a sync that feeds your pipeline or your billing, that is not a risk worth carrying. Second, HubSpot itself says not every replacement endpoint is documented yet and that full per-endpoint documentation arrives with its March 2027 release. So for some integrations the sensible plan is: inventory now, budget now, migrate in spring.
The real question is the one that sits under most HubSpot problems: who owns this, and how many hours will it take. If the answer is “nobody”, the inventory step above costs an afternoon and tells you what you are dealing with. If you have no developer or admin to run it, this is the kind of job our HubSpot admin as a service covers, and an integration inventory is part of any HubSpot audit we run.
FAQ
Will my HubSpot integrations stop working in September 2027?
Not necessarily on that day. HubSpot says the v1 to v3 APIs and legacy apps become unsupported, which means no more bug or security fixes and no guarantee they keep working. Treat September 2027 as the date after which a failure is your problem alone.
How do I know if my company uses legacy HubSpot APIs?
Open Development, then Legacy Apps in your portal to see private apps on the old model. The Migrations page and the developer home card show apps that call APIs becoming unsupported. For Marketplace apps, ask the vendor.
Do I need a developer for this?
For the inventory, no. An admin can list the apps and their owners. For the migration itself, yes. Changing API versions can change the shape of the data an integration receives, so it needs someone who can read and test the code.
Put one line in this week’s ops meeting: “list every custom HubSpot integration and its owner by the end of the month.” Once you have that list, the rest of the year is a planning problem, not an emergency.
Alignify
On this page
Get the audit checklist
All 25 checks as a spreadsheet with auto-scoring.
Talk to Alignify
45 minutes, your portal on screen, no slides. We show what we would fix first.