Skip to main content

Responding to Response Required Triggers

Invocation response modes for response required type triggers

You can specify how your application interacts with a response required (REQUEST_RESPONSE) type trigger service by selecting an invocation response mode in the Response Type dropdown when editing or creating a REQUEST_RESPONSE subscription. There are three response modes to choose from: SYNC, ASYNC, and DYNAMIC. These response modes are only available when the subscription type is set to HTTP.

Response ModesDescription
SYNCThis type of response creates a synchronous flow between the trigger service and the custom application. Once a trigger has been invoked, the custom application is expected to respond within 10 seconds. If the application takes longer than 10 seconds to respond, the trigger invocation will terminate without making any decisions.
ASYNCThis type of response creates an asynchronous flow between the trigger service and the custom application. When a trigger is invoked, the custom application does not need to respond immediately. The trigger service will provide a URL and a secret that the custom application can use to complete the invocation at a later time. The application must complete the invocation before the configured deadline on the subscription.
DYNAMICThis type of response gives the custom application the ability to choose whether it handles the invocation request synchronously or asynchronously on a per-event basis. In some cases, the application may choose SYNC mode because it is able to respond quickly to the invocation. In other cases, it may choose ASYNC because it needs to run a long running task before responding to the invocation.

Responding to response required triggers

The custom application responds to the trigger invocation with an appropriate payload. For example, the application may receive a request from the Access Request Dynamic Approver trigger. The application will have 10 seconds to analyze the event details and respond with a 200 (OK) status code and a response payload that contains the identity to add to the approval chain. For example, the response may look like this:

200 (OK)

"id": "2c91808b6ef1d43e016efba0ce470906",
"name": "Adam Adams",
"type": "IDENTITY"

Trigger invocation status

To check the status of a particular trigger invocation, you can use the list invocation statuses endpoint. The status endpoint works for both REQUEST_RESPONSE and FIRE_AND_FORGET triggers. However, the status of FIRE_AND_FORGET trigger invocations will contain null values in their completeInvocationInput since FIRE_AND_FORGET triggers don't need a response to complete.