Skip to main content

Feeds

Subscribe to registry changes, incidents, coverage gaps, and Bittensor runtime upgrades as RSS 2.0, Atom 1.0, or JSON Feed — computed at request time from artifacts already served. Read-only, no API key.

Last updated

Six GET feeds, all content-negotiated. Point any reader, crawler, or agent at a URL below — or just hand your reader a page on this site, which now advertises the right feed itself (see Autodiscovery).

GET https://api.metagraph.sh/api/v1/feeds/registry

Feeds

PathSummaryItem tags
/api/v1/feeds/registryRegistry changes from the 6h changelog deltas — subnets, artifacts, and coverage.registry + one of subnet/artifact/coverage + the change verb (added/removed/renamed/modified)
/api/v1/feeds/incidentsReconstructed incident history — one item per incident, opened and resolved.incident, sn<netuid>, and ongoing or resolved
/api/v1/feeds/gapsOpen coverage gaps — what each subnet is still missing, by queue lane.gaps, the queue lane, sn<netuid>, and each missing/direct-submission kind
/api/v1/feeds/upgradesBittensor runtime upgrades — releases, observed chain spec-version changes, BITs.chain, upgrade, and one of release/mainnet/testnet/bit
/api/v1/feeds/subnets/{netuid}Everything above, narrowed to a single subnet.the same tags as the feed each item came from
/api/v1/feeds/watch?ids=Registry changes + incidents for a set of watched entities, named in the URL.the same tags as the feed each item came from

Watchlist feed

Watchlists are local-first — starring something writes to your browser's own storage, never to an account we hold. The watch feed keeps that posture: the entity set travels in the URL, not in anything stored server-side.

GET https://api.metagraph.sh/api/v1/feeds/watch.json?ids=s1,s7,s74

?ids= is a comma-separated list of kind-prefixed entities, up to 50 per URL:

PrefixKindExample
ssubnets7
vvalidatorv5FHneW…
aaccounta5Grwva…

This URL is the credential

Anyone with this URL sees which entities it tracks. There's no account behind it and nothing to revoke — treat it like you would a private RSS link, and generate a new one (drop entities, rebuild the URL) if it leaks somewhere you didn't intend.

Only subnet ids currently resolve to items — registry changes and incidents, exactly like /api/v1/feeds/subnets/{netuid}, merged across every watched subnet. validator/account ids are accepted and counted toward the 50-id cap (so a URL built from a mixed watchlist never silently exceeds it), but there is no change-tracking data source for either yet; the feed's own description field says plainly how many of the requested ids produced nothing, rather than staying silent about the gap. More than 50 ids in one URL is a 413.

Runtime upgrades

Subtensor runtime upgrades reach mainnet with no on-chain warning — they are sudo-applied, and the Scheduler queue is empty — so the only observable signal is off-chain: a GitHub release, then a testnet deploy, then mainnet. /api/v1/feeds/upgrades carries all three.

GET https://api.metagraph.sh/api/v1/feeds/upgrades.rss

Items link to their primary source: a release item to the GitHub release, a chain item to the runtime timeline. Chain items say the change was detected at that time rather than applied — the radar polls twice an hour, so it cannot pin the upgrade instant.

No dates are predicted here. The foundation publishes no deploy schedule, so this feed reports what has happened and never when something will. If you need the current state rather than the history, GET /api/v1/runtime returns a current block with the live mainnet and testnet spec versions and a pending_upgrade of none, testnet_soaking, released_undeployed, or unknown.

The same items also appear in /api/v1/feeds/registry, so ?tag=upgrade narrows that feed to them alone.

Autodiscovery

Pages on this site advertise their feed in the document head, so a reader can find it from the page URL alone — paste https://metagraph.sh/subnets/8 into any feed reader and it resolves that subnet's feed without you hunting for it.

PageAdvertises
Any page/api/v1/feeds/registry
/subnets/{netuid}/api/v1/feeds/subnets/{netuid}

Both are offered as RSS and Atom:

<link
  rel="alternate"
  type="application/rss+xml"
  href="https://api.metagraph.sh/api/v1/feeds/registry.rss"
/>
<link
  rel="alternate"
  type="application/atom+xml"
  href="https://api.metagraph.sh/api/v1/feeds/registry.atom"
/>

JSON Feed is not advertised for autodiscovery — readers probe for RSS and Atom — but it is served at the same paths with a .json suffix, and every feed is described in the OpenAPI contract and in GET /api/v1/contracts under feeds.

Formats

Format precedence: an explicit .rss / .atom / .json suffix wins, then the Accept header, then JSON Feed as the default.

SuffixExampleContent-Type
.json/api/v1/feeds/registry.jsonapplication/feed+json; charset=utf-8
.rss/api/v1/feeds/registry.rssapplication/rss+xml; charset=utf-8
.atom/api/v1/feeds/registry.atomapplication/atom+xml; charset=utf-8

Filtering & paging

Every param composes. Use ?since= for incremental polling and ?tag= to turn one feed URL into a focused subscription.

ParamValueNotes
?tag=<tag>Narrow a feed to items carrying that tag, so one URL serves a focused subscription. An unknown tag yields an empty (but valid) feed.
?since=<ISO-8601>Only items at or after that instant, for incremental polling. A bare calendar date resolves to the inclusive start of that UTC day. Malformed input is a 400.
?until=<ISO-8601>Only items at or before that instant. A bare calendar date is inclusive of the whole UTC day (end-of-day), symmetric with since. Malformed input is a 400.
?limit=1..50Cap the number of returned items (default and hard cap 50). A larger value clamps; a non-integer or < 1 is a 400.

50 items is a hard cap

?limit= clamps at 50 regardless of what you pass — there's no way to get more in one response. Poll with ?since= for anything beyond that instead of raising the limit.

Feeds aren't part of the typed @jsonbored/metagraphed / metagraphed SDKs — they're plain content-negotiated HTTP, so any HTTP client works:

curl -s 'https://api.metagraph.sh/api/v1/feeds/registry.json?limit=10'

Responses are cached for 600s and capped at 50 items. Browse the same data: Gaps. Machine index: For agents.