Response Compression

The VulnCheck API compresses its responses for any client that asks it to. JSON compresses very well, so a compressed response is usually a small fraction of its original size. Downloads are faster, use less bandwidth, and the data is unchanged.

Compression applies to every endpoint on api.vulncheck.com, including the v3 and v4 APIs and the NVD compatibility endpoints.

Why it matters

The largest gains are on the largest responses. If you page through an index such as vulncheck-nvd2, or poll the API regularly from an integration, compression cuts the data you transfer by an order of magnitude.

A default page of /v3/index/vulncheck-nvd2, measured on the wire:

Exact savings vary by endpoint and page size. Larger pages compress better, especially with Brotli.

For you, this means:

• Faster responses, especially over slower, long-distance or congested links.
• Less bandwidth, which matters when your traffic goes through a metered connection, a proxy or a cloud NAT gateway that charges for data.
• Faster bulk pulls, because each page downloads more quickly when you paginate through a large index.
• No change to the data. After decompression the response is byte-for-byte identical to the uncompressed version. Compression doesn't change rate limits and doesn't count as an extra request.

How it works

Compression follows standard HTTP content negotiation:

1. Your client lists the encodings it can decode in the Accept-Encoding request header.
2. The API picks one, compresses the body, and names its choice in the Content-Encoding response header.
3. Your client decompresses the body before handing it to your code.

The API supports Brotli (br) and gzip. If a client accepts both, it gets Brotli. If a request has no Accept-Encoding header, or lists only encodings the API doesn't support, the response is sent uncompressed, just as before. Clients that don't ask for compression keep working without any changes.

Responses also include Vary: Accept-Encoding, so caches and proxies keep compressed and uncompressed copies separate.

Do I need to change anything?

Most clients already ask for compression and decode it for you, so you probably get the benefit already.

If you use curl, or a script that builds requests by hand, add --compressed or set the Accept-Encoding header yourself.

curl --compressed \
  --url https://api.vulncheck.com/v3/index/vulncheck-nvd2 \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer insert_token_here'

// Go's default transport requests gzip and decompresses the body for you.
// Don't set Accept-Encoding yourself: if you do, Go stops decompressing
// automatically and you have to decode the body in your own code.
request, _ := http.NewRequest("GET", "https://api.vulncheck.com/v3/index/vulncheck-nvd2", nil)
request.Header.Set("Accept", "application/json")
request.Header.Set("Authorization", "Bearer insert_token_here")

response, _ := http.DefaultClient.Do(request)
defer response.Body.Close()

# requests asks for gzip by default, and for Brotli too once the
# brotli package is installed (pip install brotli). It decompresses for you.
import requests

url = "https://api.vulncheck.com/v3/index/vulncheck-nvd2"
headers = {
  "accept": "application/json",
  "authorization": "Bearer insert_token_here"
}

response = requests.get(url, headers=headers)
print(response.headers.get("Content-Encoding"))  # br or gzip
print(response.json())

Checking that compression is working

Print only the response headers and look for content-encoding:

curl --silent --output /dev/null --dump-header - \
  --header 'Accept-Encoding: br, gzip' \
  --header 'Authorization: Bearer insert_token_here' \
  https://api.vulncheck.com/v3/index/vulncheck-kev

HTTP/2 200
content-type: application/json
content-length: 37012
content-encoding: br
vary: Origin,Accept-Encoding

If there's no content-encoding header, the request didn't advertise a supported encoding. Check that your client sends Accept-Encoding: br or Accept-Encoding: gzip.

Offline backups

Offline backups are downloaded as zip archives, which are already compressed. The JSON from the /v3/backup endpoints that lists backups and returns download links is compressed like any other API response. If you need a full dataset, a backup is still the most efficient option. It is a single download rather than hundreds of paginated requests.