Skip to main content
When using the workflows v4 API, you’ll need to set up actions and enrollment triggers for your workflows. The sections below provide an overview of the different action types and enrollment criteria when using the v4 endpoints.
Please note:This API is currently in beta and is subject to change based on testing and feedback. By using these endpoints you agree to adhere to HubSpot’s Developer Terms & Developer Beta Terms. You also acknowledge and understand the risk associated with testing an unstable API.

Action types

Each workflow specification consists of a list of actions. Each action contains a set of required properties:
  • actionId: a unique ID that identifies this action, provided as a string.
  • actionTypeId: a predefined value that specifies the action type (e.g., "0-1" designates a DELAY action). A list of actions and their associated actionTypeId is provided in the section below.
  • actionTypeVersion: a number that designates the version of the action. For all built-in action types (e.g., a delay, email notification, etc.), the actionTypeVersion will be 0.
  • connection: for non-branching actions, this property is an object that specifies the subsequent action, and contains two nested properties:
    • edgeType: to proceed directly to the next action, this property should be set to "STANDARD". If you have a branch in your workflow, you can go to an action in a different branch by setting the edgeType to "GO-TO".
    • nextActionId: the ID of the subsequent action in the workflow.
  • type: for non-branching actions, this should be set to SINGLE_CONNECTION.
  • fields: an object that specifies the data required by the action (e.g., how long to delay an enrolled object for a DELAY action). The structure of this property depends on the action type. Consult the sections and example actions below for the fields each action type expects.

Action type IDs

The table below details the available action types along with the associated actionTypeId.
  • Branches and Go to actions do not have an associated actionTypeId.
  • For integration actions, you can add the action to your workflow, then make a GET request to /automation/v4/flows/{flowId} to retrieve the actionTypeId.
Note that some actions have the same type ID, such as Delay until a calendar date and Delay until a date property. These actions are split into their own table rows to match how they appear in the workflow action sidebar.

Action fields

The fields property of your action depends on the corresponding action type.
  • The actions available depend on your account’s subscriptions. Learn more about the available actions in workflows.
  • To confirm the fields required for a specific action, you can create the workflow with that action using the workflows tool, then make a GET request to /automation/v4/flows/{flowId} for that workflow.
The sections below outline the required fields for common actions in a workflow.
In the example code blocks below, note that the nextActionId field values are demonstrative, and should contain the ID of the next action in your particular workflow.

Delay until a specific date or date-based property

The code below specifies a Delay until a calendar date action, but can also be used with a Delay until a date property action. Based on whether you’re delaying until a preconfigured date or a date-based property of the enrolled record, you’ll need to specify the sub-properties of the date field accordingly:
  • If you’re delaying until a specific calendar date, provide STATIC_VALUE for the type sub-property, then provide the calendar date for the staticValue sub-property as a unix timestamp.
  • To delay until a date-based property of the enrolled record, provide OBJECT_PROPERTY for the type sub-property, then specify the property to use as the propertyName.

Delay a set amount of time

The code below specifies a Delay for a set amount of time action.

Send an automated marketing email to an enrolled contact

The action definition below sends an automated marketing email with an ID of 12345678 to an enrolled contact.

Set property

The action definition below sets the hs_lead_status property to "IN_PROGRESS".

Create task

The action definition below creates an unassigned task:

Create a new record

The action definition below creates a new deal and associates it with the contact enrolled in the workflow:

Add an enrolled object to a static list

The action definition below adds an enrolled contact to a static list, specified as the listId.

Remove an enrolled object from a static list

The action definition below removes an enrolled contact from a static list, specified as the listId.

Branching actions

Branching actions differ from other actions in that they don’t follow the standard action structure. Branching action definitions don’t have fields or connection properties. There are two types of branching actions: list branch actions and static branch actions. Both types must also define a default branch using the defaultBranchName and defaultBranch properties.

List branch actions

List branch actions include a listBranches property that specifies a set of filter branches to segment enrolled objects. Each filterBranch is configured using the syntax and formatting outlined in the list filters documentation.

Static branch actions

Static branch actions include an inputValue definition, which supports different shapes for the input values of the branch. It also includes a list of staticBranches, which defines which actions come next in the branch.

Enrollment criteria

You can configure the conditions for objects to be enrolled in your workflow within the enrollmentCriteria property of your workflow specification.
  • The data you specify varies based on whether your enrollment is event-based or list-based. You can specify the enrollment type by setting the type of enrollmentCriteria to either EVENT_BASED or LIST_BASED.
  • You can specify the re-enrollment settings for objects enrolled in your workflow by setting the shouldReEnroll field to true or false.
Learn more about workflow enrollment triggers.

Event-based enrollment

Event-based workflows will enroll objects when specific events occur, such as when a form is submitted.
  • You can configure the criteria for which events will trigger enrollment by defining a list of eventFilterBranches. Each eventFilterBranch definition specifies a qualifying event (e.g., a form submission) using an eventTypeId that corresponds to that event.
  • Most events will have the same values for the following fields:
    • operator: "HAS_COMPLETED"
    • filterBranchType: "UNIFIED_EVENTS"
    • filterBranchOperator: "AND"
The table below defines each eventTypeId that corresponds to the event you can configure for your workflow.
The Segment membership change event enrollment trigger does not have an associated eventTypeId. Instead, it uses IN_LIST / NOT_IN_LIST operators to determine segment membership.
The example code below defines the enrollmentCriteria to enroll contacts who successfully submitted a form:

Filter-based enrollment

Workflows with filter-based enrollment will enroll records when the configured criteria is met.
  • The criteria is configured by setting the listFilterBranch field of your enrollmentCriteria, based on which objects should qualify for enrollment in your workflow. Within a listFilterBranch, you can define the specific filter criteria using a list of filterBranches.
  • Learn more about the syntax and formatting for defining a listFilterBranch.
For example, the enrollmentCriteria below defines the criteria for when a contact’s City property is equal to Dublin:
Last modified on March 29, 2026