Response Compression

Our API requires response compression for all requests when certain conditions are met. This enables us to return larger payloads while maintaining fast response times.

Currently, this applies to Messages Services that return message bodies in the response.

A response will be compressed when the following conditions are met:

• The response body is at least 10 MB in size.

• The client request includes Accept-Encoding header specifying one of the supported compression types:

Accept-Encoding Header	Details
gzip	The response will be compressed using gzip.
deflate	The response will be compressed using deflate.
gzip, deflate	The response will be compressed using gzip, as this is our preferred compression scheme.

If a message body exceeds 10 MB and the client does not support compression (i.e., does not include a supported Accept-Encoding header), our API returns an error — most likely an HTTP 500. The exact outcome may vary depending on the client’s implementation.

We recommend making use of the Accept-Encoding header containing compressed forms for all requests if possible, provided that the HTTP client in use can handle compressed payloads. This will ensure response times will be minimised no matter the overall size of the response body. Most modern HTTP clients should handle decompression out of the box, so no extra implementation would be required to read a compressed body.

We also provide a dedicated service for quick and easy compression testing. More details are available at: Get compressed message for testing