USM Content
Workflow request
With the webhook request URL, you can make a POST request to start a Bridge workflow. You can use the following request body:
{
"workflow":"workflow name or UUID",
"stateValues":{
"statename":"value"
},
"uid":"a generated unique ID for the request",
"extra_stuff":{
"lots":"of it"
}
}
- workflow: The only required field and must be set as a valid workflow name or UUID value.
- stateValues: An optional field used to preset the workflow states with the specified value.
- uid: A unique identifier (uid) used so our system ignores duplicate requests if you send the same request multiple times
- Every other field you send as part of the POST body:
- Passed to the workflow, and is referenced using the runtime handlebars, for example {{runtime.extra_stuff.lots}}, with the return of it
- Any valid JSON value will be passed
Remember that all requests to this endpoint require the Inbound-Webhook-Secret header to be set with your Secret values.
This solution doesn't support webhooks, which include a challenge request. This requires building a new custom integration.
Workflow batch requests
If you want to run more than one workflow with a single request, you can pass a batch object as part of the body request:
{
"workflow":"workflow name or UUID",
"batch":[
{
"uid": "request1",
"workflow":"alternative workflow",
"stateValues":{
"state":"value"
},
"runtimeData":{
"key":"value"
}
},
{
"uid": "request2",
"stateValues":{
"state":"value"
}
}
]
}
Notes
The batch request object uses the same fields as the main request, with the addition of runtimeData, which is used to set the data available to the {{runtime}} handlebar in the workflow.
- If you don't specify a workflow or state values in your batch request object, the values set in the parent object are used instead. In the above example, the two workflows would run request1 with the alternative workflow, and request2 with the initial workflow.
- If you want to override the parent values with nothing, set an empty object for stateValues. Undefined values are treated as not set, and the parent value will be used. The uid field from the parent object is ignored when you're using batch requests, but each batch object can set its own uid if required.
- Even if each batch object defines its own workflow, the workflow in the main request is still required.