author_name:leongersing

In order to provide the most robust, fast and accurate API for Gist we recently decided to make a few small changes to the*files*payload.

In order to provide the most robust, fast and accurate API for Gist we recently decided to make a few small changes to the*files*attribute.

Sometimes we need to put some large data into a gist. However, we don't always need to see the full content of that large gist when we're fetching the metadata for gists via the API.This change imposes a sensible (according to our data) limit on the amount of raw file data that is returned in gist fetches via the API.If you're relying on reading the full content of individual files from a gist then you mayneedto update your flow to perform a followup request forthe**raw_url** resource in order to download the entirecontents ofthefile. Which begs the question:*How do I know if thefile's contents have been truncated?*

This change imposes a sensible (according to our data) limit on the amount of raw file data that is returned in gist fetches via the API.This means faster response times while eliminating browser timeouts when fetching gists that contains large files. When youneed thefullcontents ofyour gist'sfile, simply make a request to the url specified in theraw_url attribute.

On the packets that have been truncated you will notice a new key in the files segment of the payload.

In this small example payload, you'll notice the new*truncated* key has been added and the*content* key's value is empty. This would be a case for making a follow up request to the raw_url, if you are looking to get all of the data that would have normally showed up in the content field.

In this small example payload, you'll notice the new**truncated** attribute has been added to each file's payload. It is a boolean attribute indicating if the content attribute's value has been truncated for this request.

If you have any questions, please[get in touch][contact].