/automation/v4/flows/performance has no dated successor ahead of the v4 sunset

Developer Support APIs & Integrations
5

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:

  1. 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.
  2. 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.

That is what I raised separately in https://community.hubspot.com/t/property-history-identifies-the-write-event-for-workflow-changes-not-the-workflow/157540 Happy to be wrong if there is a setting or a parameter that changes what the entry carries.

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.