Journeys

Set trigger

Changed on Nov 3, 2026

Configure how people enter the journey by updating its ENTRY node: manual, segment (needs segmentId), cdp_event (needs eventName), or inbound (needs inboundAction and inboundChannelIds, optionally narrowed to an inboundKeyword), with an optional frequency cap, or an optional parallelRunsBy on cdp_event to give one person a concurrent run per event-property value. Fields belonging to the other trigger types are cleared.

patch/api/v1/journeys/{journeyId}/trigger

Request

Base URL
https://www.useboom.ai
Auth
HTTP bearer

Path parameters

journeyIdstring required

A draft journey id, or the initiative id (resolves to its current draft).

Request body

triggerType'manual' | 'segment' | 'cdp_event' | 'inbound' required

How people enter the journey.

segmentIdstring

Required for segment triggers. The segment's id (from segments_list / segments_get) — NOT its slug.

segmentNamestring

eventNamestring

Required for cdp_event triggers.

Required for inbound triggers. INSTAGRAM_COMMENT / FACEBOOK_COMMENT listen to public comments on the account's posts instead of DMs; they require Instagram or Messenger channels whose connection was granted comment permission, and enroll the commenter without opening a conversation.

inboundChannelIdsstring[]

Required for inbound triggers: the channel ids to listen on. Must be NATIVE WhatsApp, SMS, Instagram or Messenger channels that are not deleted — WhatsApp and SMS additionally need an ONLINE sender, Instagram and Messenger have no sender row and need none (a Messenger Page still on the V1 bridge is withheld as NOT_NATIVE); if you pass an ineligible one the error names the eligible ids. For a comment action, only Instagram and Messenger channels are valid. Several published journeys may share one channel as long as their keywords differ: publishing a rule whose keyword (or blank catch-all) is already taken on that channel is refused with INBOUND_CHANNEL_TAKEN. Each arriving message enrols exactly one of them, the most specific matching rule, ties going to the older initiative.

inboundKeywordstring

The word the inbound message must match for this journey to enrol — e.g. 'PRECIO'. Blank or absent means the trigger is the catch-all and fires on ANY message arriving on the channel, which is almost never what you want beside other journeys on the same number. Several journeys may share one channel as long as their keywords differ — two rules with the same keyword on one channel, or two blank ones, are refused at publish with INBOUND_CHANNEL_TAKEN. The keyword is matched accent-, case- and punctuation-insensitively, and stored normalized.

inboundMatchMode'EXACT' | 'CONTAINS' | 'ALL_WORDS'

How inboundKeyword is matched: EXACT (the message is only-the-word), ALL_WORDS (the message contains all-the-words, in any order), or CONTAINS (the message contains-the-word, adjacent and in order). All three are word-based, so no mode ever matches inside a longer word ('precioso' does not match 'precio'). Defaults to EXACT. Ignored when inboundKeyword is blank.

maxEnrollmentsinteger

Frequency cap; both-or-neither with enrollmentWindow.

enrollmentWindowstring

Frequency-cap window, e.g. '7d'.

parallelRunsBystring

cdp_event only: let one person have several runs at once, one per distinct value of this event property (e.g. "paymentLinkId"). The journey becomes send only, the frequency cap is refused, and stop events match on the same property. See the ENTRY node docs in journeys_authoring_catalog. Cleared when the trigger changes to another type.

Response

Success

idstring required

Journey (workflow version) id.

initiativeIdstring required

The initiative this journey belongs to.

status'DRAFT' | 'PUBLISHED' | 'STOPPED' required

DRAFT (editable), PUBLISHED (live, frozen), or STOPPED (retired).

versioninteger required

Version number within the initiative.

Changes

Nov 3, 20267c7a773b12ce Revision changes
- breaking
  added subschema #1 subschema #2 subschema #3 subschema #4 subschema #5 subschema #6 subschema #7 subschema #10 subschema #13 subschema #14 subschema #15 subschema #16 subschema #17 subschema #18 subschema #19 subschema #20 subschema #21 subschema #22 subschema #23 to the // response property oneOf list for the response status
- info
  added the new optional request property
- info
  added the new optional request property
- info
  added the new optional request property
- info
  added the new optional request property
- info
  added the new optional request property
- info
  added the new inbound enum value to the request property
- info
  added the optional property /// to the response with the status
- info
  added the optional property // to the response with the status
- info
  removed subschema #1 subschema #2 subschema #5 subschema #8 subschema #9 subschema #10 subschema #11 from the // response property oneOf list for the response status

Operation history