Constructing composite requests

Information from one subrequest can be used in later subrequests. You can do this through the use of composite variables.

      "vars": [
        {
          "name": "newActivityId",
          "path": "$.data.attributes.id"
        }
      ]

${<varName>}

"uri": "/common/v1/activities/${newActivityId}/notes"

{
  "requests": [
    {
      "method": "post",
      "uri": "/claim/v1/claims/cc:34/activities",
      "body": {
        "data": {
          "attributes": {
              "activityPattern": "contact_insured",
              "subject": "Cloud API activity"
          }
        }
      },
      "vars": [
        {
          "name": "newActivityId",
          "path": "$.data.attributes.id"
        }
      ]
    },    
    {
      "method": "post",
      "uri": "/common/v1/activities/${newActivityId}/notes",
      "body": {
        "data": {
          "attributes": {
            "body": "Cloud API note #1."
          }
        }
      }
    }
  ]
}

Composite requests have the following general limitations:

• The number of subrequests and subselections in a single composite request must be less than or equal to the value of the MaximumAllowedNumberOfCompositeSubRequests configuration parameter. (In the base configuration, this is set to 100.)
• The subrequests can make use of other endpoints that are part of Cloud API. However, they cannot make use of endpoints outside of Cloud API, such as custom endpoints created by an insurer.
• You cannot use request inclusion in composite requests.
  • For more information on request inclusion, see Request inclusion.
• You cannot include a subrequest that uses a content type other than application/json.
  • For example, you cannot work with document resources in composite requests, as documents use multipart/form-data.
• You cannot use any POST /search/... endpoint in a composite request (such as the ClaimCenter POST /claim/v1/search/claims-v2 or the PolicyCenter POST /policy/v1/search/policies endpoint)
• There is no mechanism for iterating over a set of things.
  • For example, you cannot start with a list of elements and include related resources for each item in that list.

There may be some business requirements where you are required to use a composite request. For example, when creating a new claim with an unverified policy, you must create the policy and claim in a composite request.

There are also specific business requirements where you cannot use a composite request. For example:

• You cannot have a single composite request operate on more than one claim.
• For service requests that are Quote Only, Quote and Service, or Service Only, you can create and submit a service request in a single composite request. But you cannot advance these types of service requests to any other stage in its life cycle (such as in progress, declined, or canceled at the vendor’s or insurer’s request) in the same composite request.
• Within a composite request, the only financial object you can create or modify is final non-recurring check sets. You otherwise cannot create or modify financial objects. This includes reserve sets and reserve transactions, recurring check sets and payment transactions, and the check life cycle endpoints (such as POST /mark-issued). However, within a composite request, you can GET information on financial objects.

Many of the examples in the previous list pertain to situations where there must be an intermediate data commit, which composite requests do not allow by design. However, the previous list is not intended to be exhaustive. Refer to the section of the documentation that discusses each business requirement for more information on requirements or limitations related to composite requests.

This documentation includes examples of composite requests for common business tasks. This includes the following:

• Creating a new claim with an unverified policy: Sample composite claim payload
• Creating, closing, and paying out a claim: Sample composite first-and-final