Changes to list membership actions in the v4 Automation API

Developer Support Developer Announcements
,
1

What’s changing?

The “alter list membership” action ("actionTypeId": "0-13") is being split into two distinct actions: “add to list” (actionTypeId 0-63809083) and “remove from list” (actionTypeId 0-63863438). These new separate action types will be used instead of including the "operation": "REMOVE" or "ADD" in the fields data for the step.

Previously, this was the format for a step to remove a record from a list:

{
 "actionId": "3",
 "actionTypeVersion": 0,
 "actionTypeId": "0-13",
 "fields": {
 "operation": "REMOVE",
 "list_id": "1234"
 },
 "type": "SINGLE_CONNECTION"
}

This is the updated format to remove a record using the new action type:

{
 "actionId": "3",
 "actionTypeVersion": 0,
 "actionTypeId": "0-63863438",
 "fields": {
 "listId": "1234"
 },
 "type": "SINGLE_CONNECTION"
}

This change is part of a broader effort to make actions more consistent, so that each operation has its own action type instead of using an action type with a separate operation field.

When is this happening?

This change has already been applied to existing workflows, resulting in updated API responses reflecting the new action types.

While we recommend updating to the new action types as soon as possible, the “alter list membership” action ("actionTypeId": "0-13") can still be used for now. Keep in mind that any workflows created or updated using this type will be converted to the appropriate separate action types, meaning that the API response for the workflow will not match the original JSON sent by your integration.

See the Workflows API documentation for more details. Please let us know if you have any questions by replying below.

2

Thanks for the announcement — for anyone landing here from a Google search on the split, wanted to add three related gotchas that hit us in the same v4 Automation namespace while migrating off the old `actionTypeId: “0-13”`.

**Silent 500 on the legacy ID.** Before the deprecation grace period was documented, `POST /automation/v4/flows` with the old `“actionTypeId”: “0-13”` returned HTTP 500 with an empty body against certain object types — no hint that the ID was being converted server-side. The new `“0-63809083”` (add) and `“0-63863438”` (remove) are 200 immediately and self-documenting in the response.

**Top-level `type` must match `objectTypeId`.** Adjacent to the list-membership work, `POST /automation/v4/flows` requires a top-level `type` field that must match the `objectTypeId`. Omitting it 400s with `Some required fields were not set: [type]` (reads like a missing property, actually a missing discriminator). Mismatch 400s with `Expected an object type other than “0-1” objectType but got “0-1”` — blames `objectTypeId`, but the culprit is `type`. Verified: `CONTACT_FLOW` for `0-1`, `PLATFORM_FLOW` for `0-3`.

**ENUMERATION-property operator allowlist is narrower than CRM Search.** `IS_NOT_EQUAL_TO` 400s. Use `IS_NONE_OF` with a single-element `values` array; add `includeObjectsWithNoValueSet: true` if nulls should also match.

**Unified-events filter branches cannot nest.** Nested `filterBranches[]` inside a `UNIFIED_EVENTS` entry returns 400: `Unified events filter branches cannot have any nested filter branches`. Fix: promote each condition to its own top-level `eventFilterBranches[]` entry (implicitly OR’d).

Full reproducible request/response pairs, allowlist table and verification recipe: https://www.elemra.com/learn/hubspot-flows-v4-api-errors

e the deprecation grace period was docume

1 Like