/automation/v4 carries a sunset date of 30 March 2027. Working through what a migration looks like, one endpoint appears to have no dated replacement.
The 2026-09-beta namespace publishes flows, flows/batch/read, flows/email-campaigns, flows/{flowId}, action-types and the new flows/{flowId}/revisions/{revisionId}. It does not publish flows/performance/{flowId}.
Is a dated variant planned, or is the endpoint being retired at the sunset?
Why it matters to us: flows/performance is the only public read of per-flow enrolment volume. It is what separates a workflow that runs from one that has not fired in two years, and there is no other way to ask that over the API. We use it read-only, in an audit tool, on the automation scope.
Two documentation issues on the same endpoint, offered as a fix rather than a complaint. The published OpenAPI spec marks start, end and bucketType as optional; all three are required, and a request without them returns 400. That 400 names the missing attribute as bucket, while the query parameter is actually bucketType, so the obvious correction fails with the identical error. bucketType accepts DAY, WEEK and MONTH; HOUR, QUARTER and YEAR return 400.
I’ve taken a look internally and upon further review it appears there is not a public facing roadmap for flows/performance/{flowId} just yet. That said, I’d like to tag some from folks from the community to see if they have a recommended migration path for this!
(If you’re not able to find a workaround this may be best suited for our Ideas Forum in the meantime)
You’ve read it right, no dated successor for flows/performance yet, and no roadmap. But I wouldn’t assume retirement: 2026-09-beta has been growing mid-beta (revisions wasn’t there at launch either). The important move: don’t just drop this on the Ideas board, open a support ticket framed as a v4 sunset migration gap. “Endpoint has no migration path before its own sunset” gets triaged very differently from a feature request.
Meanwhile you have 13 months of runway, so I’d:
Wrap flows/performance behind an adapter and keep using it until March 2027, swap becomes one module later.
Build a fallback for “alive vs dead”: for email workflows, flows/email-campaigns > email statistics per campaign is a decent activity proxy. And workflow-made property changes show up in property history with source AUTOMATION_PLATFORM + the flow id, not volume, but enough to catch “hasn’t fired in two years” on spot-checks.
On the doc bugs, good catches. The bucket vs bucketType thing is the internal param name leaking into the error. Bundle both (plus the wrong optional flags in the spec) into the same support ticket so they reach the API team, not just docs.
I’ll circle back here if i hear anything about a dated performance endpoint.
Thanks @Alex_Boissonneault, that is the steer I needed, and I will frame it as the migration gap rather than a feature request.
One practical question before I do: how do I open that ticket? We are a Technology Partner at the Partner tier with a published app, and the Technology Partner page offers no support route, only an address to email. If there is a developer support form I am missing, point me at it and I will file there. Otherwise I will send it to technology-partners@hubspot.com and ask them to route it to the Automation API team.
Two notes back:
On the beta still growing, that matches what I see from outside.2026-09-beta publishes flows, flows/batch/read, flows/email-campaigns, flows/{flowId}, action-types and flows/{flowId}/revisions/{revisionId}. That last one has no v4 equivalent, so the namespace is clearly still accreting rather than frozen. Good reason not to read the gap as a decision.
On the property-history fallback, that one does not work, and it is worth flagging precisely because it is the obvious thing to reach for. An AUTOMATION_PLATFORM history entry does not carry a flow id. It carries sourceId: "enrollmentId:<id>;actionExecutionIndex:<n>", and across 28 entries on a live EU1 Enterprise portal every one of those ids appeared on exactly one record: it identifies the write event, not the writer. For comparison, in the same sample CRM_UI entries carry userId:<id>, and one of those spanned eight records.
There is also no published endpoint that resolves a workflow enrollment back to a flow. Across the OpenAPI specs the only enrollments paths are sequence enrollments, which are a different object.
So a person who changed a field is attributable through the API today, and a workflow is not.
flows/email-campaigns is a good pointer for email-sending workflows, thanks: it takes an optional flowId on the same automation scope. It will not cover the property-writing workflows I am measuring, but it is a real partial.
On the adapter, already done: the endpoint sits behind a single constant and one function, so a swap is a two-line change whenever there is something to swap to.
Hey @birdman, On the ticket route: don’t use the technology-partners@ inbox for this, that lands with partnership/BD, not engineering. Since you have a listed app, you have developer support access: log into the developer account that owns the app listing and use the Help widget there (bottom right), a listed marketplace app is what unlocks ticket submission in that account even without a paid hub. File it there with your correlationId, and separately ping your Partner Manager via the technology-partners address asking them to watch the ticket, the nudge from partnerships plus a properly filed ticket moves faster than either alone.
On property history, you’re right and I stand corrected. I hadn’t looked closely enough at what sourceId actually carries for AUTOMATION_PLATFORM; enrollmentId:<id>;actionExecutionIndex:<n> identifying the write event rather than the writer is a genuinely useful finding, and your 28-entry sample is exactly the kind of evidence that thread needed. Thanks for doing the work I should have.
One thought: that finding strengthens your migration-gap ticket. Put them together, “property history can’t attribute a write to a flow, and flows/performance is being sunset with no successor” means that after March 2027 there is zero public API surface connecting workflow activity to workflows. As one combined statement that’s a much harder gap for the API team to wave off than either issue alone.
And it seems like your adapter’s already where it needs to be. I’ll flag here if a dated performance endpoint shows up in the beta.
Thanks for the detailed follow-up. The distinction between the write event and the actual workflow is really useful. I’ve run into similar tracking issues while working with lead workflows for dumpster rental businesses, where knowing whether an action actually came from a specific workflow can make a big difference when auditing leads. The adapter approach sounds like a sensible way to keep things stable until HubSpot provides a proper successor.
Thanks. I chased that down, and it does not work for a free developer account. Recording what happened in case it saves someone else the hour.
The widget is the ? in the top nav rather than bottom-right, and it opens. But on the developer account that owns our published listing, its Support section offers an Academy search, a knowledge-base box, “Search HubSpot Community” and “Start live chat”. No Contact Us, no email, no phone. The live chat then routed me to HubSpot Sales, who told me the way to raise a ticket is to “log in to your paid account” and use Contact Us there and sent a screenshot of the entitled Help Center, which carries Chat, Email and a phone number. Ours carries neither.
I asked Sales to confirm it rather than infer it, and they did, in writing: “Yes, tech support is only for paid plan or trial account.” For developers they pointed at the docs, this forum and the Developer Slack.
So support entitlement follows a paid hub rather than a published Marketplace listing. A published app on a free developer account does not unlock ticket submission. Worth knowing before anyone else spends the hour.
Which leaves the gap without a triage route, and it is the combined one you suggested: property history cannot attribute a write to a flow, and flows/performance has no dated successor, so after 30 March 2027 there is no public API connecting workflow activity to workflows. Either fix closes it: a dated flows/performance, or flowId on AUTOMATION_PLATFORM history entries.
If anyone reading knows the route an app partner is supposed to use for an API migration question, I will file there today. Otherwise it stays in these two threads.