GitHub's synchronous SBOM endpoint reached its sunset date today, November 13, 2026. At 15:58 UTC this morning it still answered 200 OK.

It came with its own death certificate attached. Every response now carries these two headers:

deprecation: Tue, 12 May 2026 00:00:00 GMT sunset: Fri, 13 Nov 2026 00:00:00 GMT

So by its own account it died at midnight UTC, and nearly 16 hours later it was still handing out SPDX files. I would not read that as a reprieve. GitHub's changelog says it is "slated for removal" on November 13, and it can go between one request and the next.

The record

Name GET /repos/{owner}/{repo}/dependency-graph/sbom
Born April 12, 2023, when GitHub added an SBOM REST API
Known for one call, one SPDX 2.3 document, for the head of the default branch
Weakness a hard-coded ten-second timeout that large repos often hit
Deprecated May 12, 2026 (changelog)
Sunset November 13, 2026
Survived by about 4,300 files on GitHub that mention dependency-graph/sbom and neither of the new paths
Replaced by generate-report, then fetch-report

The file count is GitHub code search for "dependency-graph/sbom" NOT "generate-report" NOT "fetch-report", read November 13, 2026. It is rough: it includes docs, forks and some files that only mention the path. For comparison, about 1,100 files already name the new generate-report path.

Why it was retired

The timeout. GitHub's April 14 changelog says the old export "had a hard-coded timeout value of ten seconds", which often was not enough for big dependency trees. The new flow computes the SBOM in the background and caches it.

What replaces it

Two calls instead of one:

  1. GET .../dependency-graph/sbom/generate-report returns 201 with an sbom_url.
  2. GET that URL. It returns 201 while the report is being built and 302 to the file when it is ready.

Here is a 14-line drop-in for scripts that used the old call:

#!/usr/bin/env bash # Usage: ./sbom.sh owner/repo > sbom.json (set GITHUB_TOKEN for private repos) set -euo pipefail api="https://api.github.com/repos/$1/dependency-graph/sbom" auth=(-H "Accept: application/vnd.github+json") [ -n "${GITHUB_TOKEN:-}" ] && auth+=(-H "Authorization: Bearer $GITHUB_TOKEN") url=$(curl -fsS "${auth[@]}" "$api/generate-report" | jq -r .sbom_url) for i in $(seq 1 30); do code=$(curl -sS -o /dev/null -w '%{http_code}' "${auth[@]}" "$url") [ "$code" = 302 ] && exec curl -fsSL "${auth[@]}" "$url" [ "$code" = 201 ] || { echo "unexpected HTTP $code" >&2; exit 1; } sleep 2 done echo "timed out waiting for $url" >&2; exit 1

I ran it this morning against cli/cli without a token. It finished in about 2.5 seconds and wrote a 366 KB SPDX 2.3 document with 302 packages. It needs curl and jq.

Where the old call hides

Check CI workflows, compliance scripts and anything that runs on a schedule, since those fail quietly:

git grep -n "dependency-graph/sbom" | grep -v -e generate-report -e fetch-report

If your HTTP client logs response headers, a sunset header is worth alerting on. GitHub sent one on every response I got from the old endpoint this morning.

Do you alert on Deprecation and Sunset headers anywhere, or do you find out when the call fails?

I'm Nabil. I build Since, which tracks what your code depends on and tells you before it breaks.