I am building a read-only audit that reads a portal’s workflows through the Workflows API v4, using a key the portal’s own admin creates. In a developer test account (Enterprise trials active), the API does not return workflows built in the workflow editor.
What I did:
Created a contact-based workflow in the editor: manual trigger only, a 15-minute delay, “Rotate record to owner”, then “Edit record” setting Contact owner. Turned it on. Flow ID 4993100991.
Created a Service Key with only the automation scope, then separately a legacy private app with only automation.
With each key:
GET /automation/v4/flows returns {"results": []}, although the account has five workflows (four were created with the account).
GET /automation/v4/flows/4993100991 returns 403: “Access denied. Flow must be accessible via external APIs and contain no sensitive properties unless appropriate sensitive data scopes are provided.”
GET /automation/v3/workflows returns {"workflows": []}.
Great questions!! A few things worth flagging while our others chime in:
The v4 Workflows API is still in beta, and there are known limitations around which workflows it can surface. Heres a related thread that may be useful: Workflow not accessible via Workflow v4 API.
The scope issue would concern me almost as much as the missing workflows.
If this is meant to be a read-only audit, I wouldn’t give the audit process an “automation” credential that can also modify or delete workflows unless there’s no alternative. That turns an observability tool into something with production write access.
The empty collection is also important. I’d avoid treating “/flows” as a complete inventory until HubSpot confirms exactly which editor-created workflows are externally accessible. Otherwise the audit can look healthy while silently missing workflows.
For now I’d probably make “workflow coverage unknown/incomplete” an explicit state in the audit rather than interpreting an empty result as zero workflows.
Would be very useful to get clarification from HubSpot on both pieces: what makes an editor-created flow externally accessible, and whether a genuinely read-only workflow scope is coming.
Hmm… I feel like something is broken with the flows API endpoint, right now.
I created a new service key with just automation scope and at first it pulled 2 of the 5 workflows in my test account. 1 of them was used in the new builder so that could possibly be excused. No idea why on the other two.
However, I went and edited one of the Workflows (adding Edit Record → Contact Owner → Replace action) and then that workflow disappeared from my list. Removing the action did not remake it appear.
Created a new workflow. It appeared in the API list. Added a Edit Record → Contact Owner → Clear. Still showed up. Changed it to Replace (instead of Clear). Disappeared from list. Removed the action, still not appearing.
My guess is that this action (Edit Record) is not supported in v4 (or in 2026-09-beta) right now which is why it’s not showing (as per link provided by Sam). Unsupported Workflow Actions will cause it to not show up in the API request, unfortunately.
Hey @DevRF! According to me, this is a v4 limitation, not a config issue.
“Accessible via external APIs” isn’t a toggle. It just means the workflow has an action v4 can’t represent yet. When that’s the case, the flow drops out of the list and the single GET returns that 403. The four default test-account workflows fall into the same bucket, hence the empty list.
I would suggest, you should test it.. create a contact workflow with only a delay, enable it, call /automation/v4/flows. It’ll appear. Add your actions back one by one – “Rotate record to owner” is almost certainly the culprit.
For your audit, treat “exists but not visible via API” as an expected state and surface it to the customer, rather than as an error.
