Firing an Event

All events are fired the same way. The only difference between them is the payload they send. Here's a skeletal example:

POST: https://api.{ENV}.dais.com/ioi/v3/event/fire

{
  "lineId": "<UUID of the product>",
  "type": "<event name>",
  "agencyCodes": ["<for some events, agency codes are required>"],
  "payload": {
      <specific to each event>
  }
}

Once the event is fired, there could be many actions that get executed. Each may be different. For example, event GET_QUOTES may have actions that will:

Send the email;
Hit a web-endpoint and pass the client data;
Request a quote from a carrier-integrated API;
Use the Rating action to generate a quote within the platform.
etc.

Any one of these actions could be defined multiple times withing the same event. For example, the Rating action is often defined multiple times in order to generate a variety of quoting options.

Fired event request/response

Let's consider we're firing an event GET_QUOTES.

Request Payload

curl  --location --request POST 'https://api.{ENV}.dais.com/ioi/v3/event/fire'
      --header 'Authorization: Basic <key>' \
      --header 'Content-Type: application/json' \
      --data-raw '{
        "lineId": "1c2383a1-03d1-4630-8a09-f99de2958d0c",
        "type": "GET_QUOTES",
        "payload": {
            "clientId": "<optional field, otherwise UUID of the existing client>",
            "effectiveDate": "2022-09-17",
            "intake": {
              "client.name": {
                "type": "ANSWER",
                "answer": "Company A",
                "qid": "client.name"
              },
              "client.industry.naics": {
                "type": "ANSWER",
                "answer": "451130",
                "qid": "client.industry.naics"
              },
              "addresses": {
                "type": "LOOP",
                "qid": "addresses",
                "iterations": [
                  {
                    "iterationId": "f4c41c8d-ffb6-4883-902b-ab6357fc1a54",
                    "answers": {
                      "client.address1": {
                        "type": "ANSWER",
                        "answer": "123 Main St",
                        "qid": "client.address1"
                      },
                      "client.city": {
                        "type": "ANSWER",
                        "answer": "Chicago",
                        "qid": "client.city"
                      },
                      "client.state": {
                        "type": "ANSWER",
                        "answer": "IL",
                        "qid": "client.state"
                      },
                      "client.zipCode": {
                        "type": "ANSWER",
                        "answer": "60089",
                        "qid": "client.zipCode"
                      }
                    }
                  }
                ]
              }
            }
          }
      }'

The response for this event firing will return a payload that contains 4 data points:

triggerRequestId: This is a unique identifier by which all subsequent action executions are tracked;
executedActionCount: Specifies how many actions have been executed;
expectedResponseCount: Specifies how many actions will provide some type of response - in this specific case that means, how many quotes to expect in return;
metadata: event specific payload. For this particular event, it returns the UUID of the newly created client (since the clientId was not specified in the request.)

Response Payload

{
    "triggerRequestId": "67c3d2a1-09d6-4f9e-b15c-cbae6ed491d2",
    "executedActionCount": 7,
    "expectedResponseCount": 3,
    "metadata": {
        "client": {
            "clientId": "3729dca8-fe0a-4d67-ae45-fb0e33de16c2"
        }
    }
}

Asynchronous responses to action requests

Because of the disjoint nature of the actions, they are executed asynchronously. However, the response to the event firing will tell us how many responses to expect - as not all actions generate a response (email sending, for example).