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 are also specific business requirements where you cannot use a composite request. For example:

• You cannot quote a job unless that job is created and quoted in the same composite request.
• You cannot bind-only or bind-and-issue in a composite request.

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.