Should ECC Queue payload limits be raised for large SOAP/REST responses?<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Quick answer: No, it is not best practice, is dangerous, and there are safe alternatives. Longer answer: RESTMessageV2 and SOAPMessageV2 APIs, when executing via a MID Server and the RESTProbe/SOAPProbe, only support transferring the request body and input response body via the ECC Queue payload field. The ECC Queue is not designed for massive payloads, and so the RESTMessageV2 and SOAPMessageV2 APIs are unsuitable for massive REST/SOAP responses. Reducing the size of the data per payload is one solution, although will make the design of the integration more complicated. Pagination of the results, where each request is limit to a subset of rows/data, and multiple requests are made for the full set. The Integration Hub actions for outbound REST and SOAP Messages solve this limitation in RESTMessageV2 and SOAPMessageV2 by using the IPaasActionProbe, which transfers data via the instance's Flow APIs instead. The MID Server parameter mid.eccq.max_payload_size defaults to 20MB (20000000) for a very important reason, which is that if set to more than that, you will risk instance performance impact. For historical reasons, the conditions of Integration Hub, Orchestration, and Discovery sensor business rules need to parse the payload data to read the skip_sensor parameter, to determine if an ecc_queue input is for these features or not. Turning a massive payload.txt attachment into an object in appnode memory, then turning that into an XML object, which is then searched for the parameter, is a very memory intensive operation and for e.g. a 50MB input response payload, this could use >800MB of appnode memory, which is too much. That will cause performance degradation, and possibly also out-of-memory restarts, and that's a bad thing. Discovery tries to limit itself to <5MB for a payload. Because of this limitation, other features dealing with large data, such as Event collectors, Export Sets, EDM Bulk Import, and Attachment Creator, will use instance REST APIs for data transfer as well.