Why are workflow user IDs missing in HubSpot API responses?

Develop, Build & Integrate APIs & Integrations
1

What happens

A “Send internal email notification” action (actionTypeId 0-8) saves its
recipients fine in the workflow editor and HubSpot delivers to them. But
GET /automation/v4/flows/{flowId} returns the action with no user_ids
field at all – not empty, absent. team_ids and owner_properties on the
same endpoint are unaffected.

Reproduction (developer test account [ID], built in the UI today)

One contact-based workflow, three notification actions:

action recipients set in the editor fields returned by the API
1 one user body, subject
2 the same user + “Contact owner (Enrolled contact)” body, subject
3 one user + one team body, subject, team_ids

Action 3 is the useful one: the team survives on an action saved the same day,
so this is specific to the user half rather than to the recipient block.

The complete action object for action 1, every value omitted:

actionId, actionTypeId, actionTypeVersion, connection, type,
fields: { body, subject }

There is nowhere else in the payload a recipient could be.

Expected: fields.user_ids naming the users the editor shows.
Actual: the key is absent.

It appears to depend on when the action was last saved. Across three
portals, every action still returning user_ids was last saved 2025-03-24 or
earlier; every action returning nothing was last saved 2026-08-26 or later.
team_ids and owner_properties come back across that whole range. So it looks
like a change in what gets persisted or returned on save, somewhere between
those dates.

Why this matters beyond one endpoint: because it depends on saving, it
spreads through ordinary use. Every workflow anyone edits from now on loses its
user recipients from the API, with nothing failing to signal it. Any tool that
audits or documents workflow notifications silently goes blind, and worse,
reads an action as having no recipients when it has two.

/automation/v4/action-types still declares user_ids on 0-8, so the field
is writable and no longer readable.

Is this intentional? If it is, the action-types schema should say so, because
right now the documented shape and the returned shape disagree.

Moderator note: For information, the HubSpot Community is a public space. I have therefore edited your content for security & confidential reasons.

3

Hi @birdman, I hope that you are well!

Thanks for reaching out to the HubSpot Community and for the details you shared!

From what I can see here: Retrieve a workflow - HubSpot docs , this doesn’t look like the expected behavior, so I’ll investigate this with the Team.

I’ll reach out via DM about this.

I’d love to hear from our Top Experts in the meantime, Hi @Anton, @evaldas and @sylvain_tirreau have you ever encountered something similar, please?

Thanks so much and have a lovely day!

Bérangère

5

Hi @birdman

This is something that shouldn’t be happening. However, since there is no error in the response and this change is not mentioned in any of the recent HubSpot documentation updates, it is quite strange.

I would recommend contacting HubSpot Support and flagging this issue with them. They should be able to investigate it further and provide more clarity on what is actually happening.

I hope this helps you out. Please mark it as Solution Accepted and Like to help another Community member.
This post was created with the assistance of AI tools

Thanks!

6

Your repro is pretty convincing, especially with team_ids still coming back on the same action.

The main thing I’d watch is treating missing user_ids as no recipients. A missing key and an empty list are different states. In your action 3 example, the editor has a user + team but the API only exposes the team

For an audit tool, I’d mark that user recipent state as unknown rather than zero and keep the raw response for later reconciliation.

I’d also include the action-types result in the support ticket. If 0-8 still declares user_ids but the flow response silently omits it, that’s a useful inconsistency for HubSpot to reproduce

7

Hi @birdman and all,

Sharing here what we discussed via DM too. I’m glad to let you know that the team implemented a fix and you should no longer see this behavior going forward.

If you run into anything else, feel free to reach out!

Thank you and enjoy the weekend!

Bérangère

9

Thanks Bérangère, confirmed. I re-read the repro workflow without re-saving it, and all 3 notification actions return user_ids again, alongside the team and owner recipients.
Good to know the notifications themselves were never affected. I’ll send a link if anything else turns up.
Have a good week!

10

Thanks Mahdi. HubScan already treats it that way: an action with no readable recipient key is reported as “unreadable” and left out, not flagged as empty.
For anyone who finds this later: HubSpot has since shipped a fix that also covers past saves, and I’ve confirmed user_ids comes back on the original repro workflow without re-saving it.