API responses can now be gzip-compressed

We're enabling gzip compression on Samsara API responses. When your client sends an Accept-Encoding: gzip request header, the API may return the response body compressed and set a Content-Encoding: gzip response header. This reduces response size and speeds up transfers.

Compression only happens when your client asks for it. If your request does not include Accept-Encoding: gzip, responses are returned uncompressed, exactly as they are today. The response contents and structure are unchanged — only the transfer encoding differs.

Most integrations need no changes. Standard HTTP clients advertise Accept-Encoding: gzip automatically and transparently decompress the response, so you keep receiving normal JSON without doing anything.

What to check: if your client sends Accept-Encoding: gzip — many HTTP libraries add this header for you by default — but does not decompress Content-Encoding: gzip responses, it will receive compressed bytes it cannot parse. Make sure your client decompresses gzip responses. If you cannot support compressed responses, send Accept-Encoding: identity (or omit the Accept-Encoding header) and responses will be returned uncompressed.

Only responses larger than roughly 1400 bytes are compressed; smaller responses are always returned uncompressed.

This change will roll out gradually beginning August 17, 2026. If you have an integration that can't be updated in time, contact [email protected] and we can defer the rollout for your organization.