Dynamics 365 Business Central: compressing API responses at max.

In the last part of the session I’ve done with Duilio at BC TechDays this year on how we handle large Dynamics 365 Business Central customers, I talked about different APIs optimizations we’ve done to support high throughput and large volumes.

One of the question received after the session was how to reduce the bandwidth usage when an external application needs to massively call a Business Central API and when the data returned (Json payload) is big.

Dynamics 365 Business Central APIs uses HTTP compression in response. By default, when you call a Business Central API, this is the response you receive:

OData API compression refers to the technique of reducing the size of data transmitted between an OData client and server using compression algorithms like gzip. This reduces bandwidth usage, speeds up data transfer, and improves overall API performance. 

OData, as a REST-based protocol, leverages HTTP, allowing both client and server to negotiate compression through the Accept-Encoding and Content-Encoding headers. 

To enable compression in OData API requests and responses, you need to use the Accept-Encoding header in the request and optionally the Content-Encoding header in the response. The Accept-Encoding header tells the server which compression algorithms the client can understand, while the Content-Encoding header indicates which algorithm the server used to compress the response. 

The process is the following:

• When making an OData API request, the client includes the Accept-Encoding header, specifying the compression algorithms it supports.
• If the server supports compression and the client’s requested algorithms, it compresses the response body using one of the specified algorithms (usually the first one listed that it supports). 
• The server also sends the Content-Encoding header in the response, indicating which compression algorithm it used. 
• The client receives the compressed response and decompresses it using the algorithm specified in the Content-Encoding header. 

GZIP is the standard compression type for Business Central APIs. But OData also supports other compression types, like for example Brotli.

Brotli is a high-efficiency, lossless compression algorithm developed by Google that achieves higher compression ratios compared to traditional algorithms such as gzip. 

To use Brotli as compression type in your Business Central API responses, the client need to send an API request with the Accept-Encoding: br request header:

and the server will send you a response compressed using Brotli algorithm:

The gain in terms of compression size of the response compared to GZIP is a lot. To show you that, I’ve used a custom Business Central API (working on the Item table) and here are the results of the response size (in Kb) using GZIP (default) and Brotli compression when asking for different sets of items (1,10,100,1000, 10000).

Here is the response time and size when retrieving 1000 items using gzip compression:

and here the same when using Brotli compression:

The below charts show the response size on these 5 cases using the two mentioned compressions:

Retrieving 1 item:

Retrieving 10 items:

Retrieving 100 items:

Retrieving 1000 items:

Retrieving 10000 items:

And because often a table is more clear than many fancy graphs, here are the real numbers:

As you can see, using Brotli compression the size of the API response is drastically reduced (to retrieve 10.000 items we moved from around 11MB for standard GZIP response size to 515 Kb using Brotli compression).

What to do at client side to handle Brotli-compressed API responses?

If you want to use Brotli compression for calling Dynamics 365 Business Central APIs from an external client, you need to send an HTTP request with the Accept-Encoding: br request header parameter and you need to decompress the response when returned from the API itself.

Doing that in C# it’s very easy, because .NET supports the possibility (when using HttpClient) to support automatic decompression of the HTTP content response.

You can declare your HttpClient object as follows:

HttpClient client = new HttpClient(new HttpClientHandler
{
    AutomaticDecompression = DecompressionMethods.Brotli
});

client.DefaultRequestHeaders.AcceptEncoding.Add(new System.Net.Http.Headers.StringWithQualityHeaderValue("br"));

and then all the response decompression will be handled automatically:

//Send API request to Business Central
HttpResponseMessage result = await client.GetAsync(requestUrl);

//Read the content of the API response
string content = await result.Content.ReadAsStringAsync();

Conclusion

If you have strict bandwidth requirement, remember that Brotli compression provides better compression ratios than gzip. This type of compression reduces a lot the size of the transmitted data and this can be extremely useful for high-traffic applications where minimizing bandwidth consumption and download times is crucial. 

Using Brotli compression could sometimes result in a bit overhead from the server side (so your API call could take a bit more time to answer) but personally I’ve no experienced a significant difference on that.

Original Post https://demiliani.com/2025/06/23/dynamics-365-business-central-compressing-api-responses-at-max/