Composite request limitations

General capabilities and limitations

Capabilities

Composite requests have the following general capabilities:

• The subrequests can make use of the following types of endpoints:
  • Endpoints that are part of the base configuration
  • Extension endpoints that have been created through the REST endpoint generator
• For base configuration endpoints, the subrequests can make use of extension fields added to the endpoints through schema configuration, as described in the topic on Adding Properties to Resources in the Cloud API Developer Guide)

Limitations

Composite requests have the following general limitations:

• The subrequests cannot make use of the endpoints that have been created outside of Cloud API, such as custom endpoints created directly on the REST API Framework
• 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.)
• You cannot use request inclusion in composite requests.
  • For more information on request inclusion, see Request and response 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). This is primarily because there is no way to guarantee that a POST /search/... endpoint will return a single result.
• 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.

Supported endpoints and query parameters

By default, all endpoints can be used in a composite request. If an endpoint cannot be used in composite requests, the definition of the endpoint includes allowForCompositeApi: false. You can search for this value in the swagger file itself. You can also search for it in the output of the /swagger.json and /openapi.json endpoints. Be aware that in the endpoint output, the value appears as x-gw-allowForCompositeApi: false.

By default, no query parameters can be used in a composite request. If a query parameter can be used in composite requests, the definition of the query parameter includes allowForCompositeApi: true. You can search for this value in the swagger file itself. You can also search for it in the output of the /swagger.json and /openapi.json endpoints. Be aware that in the endpoint output, the value appears as x-gw-allowForCompositeApi: true.

Business-specific limitations

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.