llms.txt and agent endpoints

Everything on this site is also published in formats meant for programs rather than browsers: an index of every page, the full text of every page, the raw markdown of any single page, and JSON manifests for the facts that change without anyone editing a page. No API key and no authentication.

If you are an agent working through a task rather than looking up a format, start at the agent quickstart.

At a glance

llms.txt

An llmstxt.org (opens in a new tab) index. After a site summary, every page appears as a single line:

- [Page title](https://docs.allora.network/path): One-line description.

Pages are grouped under an H2 per top-level section (Get Started, Build on Allora, Consume Inference, Operate the Network, Learn, Reference) and listed in site navigation order — the same order as the sidebar.

curl -s https://docs.allora.network/llms.txt

llms-full.txt

The complete text of every page, concatenated in the same navigation order. Each page is introduced by a thematic break, its title as an H1, the canonical URL it came from, and its description (indented here so this example cannot be mistaken for a real page boundary — in the file itself these lines start at column 0):

  ---

  # Page title

  Source: https://docs.allora.network/<page path>

  One-line description.

  ...page body as markdown...

curl -s https://docs.allora.network/llms-full.txt

To recover per-page boundaries, split on lines matching ^Source: https://docs.allora.network/ — one per page, in the same order as llms.txt, each preceded by the page's H1. Counting them is a cheap check that you have the whole file:

curl -s https://docs.allora.network/llms-full.txt |
  grep -c '^Source: https://docs.allora.network/'

Anything indented, or inside a fenced code block, is page content rather than a delimiter. If you only need one page, fetch its raw file instead.

Raw markdown for one page

Every page is also published on its own as plain markdown under /raw/, served as text/markdown; charset=UTF-8.

URL convention

Take the page's path, prefix it with /raw/, and append .md:

That rule covers landing pages too: /build/reputer is a section landing page with /build/reputer/build-a-reputer and its siblings beneath it, and its raw file is still /raw/build/reputer.md.

The one shape it does not cover is a landing page whose source file is named index, which keeps that name under /raw/. Today /get-started is the only one: it is at /raw/get-started/index.md, and /raw/get-started.md does not exist. So the complete two-step rule is append .md; on a 404, retry with /index.md:

curl -sf https://docs.allora.network/raw/get-started.md ||
  curl -s https://docs.allora.network/raw/get-started/index.md

The mapping is total: every page listed in llms.txt has exactly one raw file, and every raw file corresponds to a live page. Files belonging to renamed or removed pages are pruned at build time, so nothing stale is ever left behind under /raw/.

What a raw file contains

The page's YAML frontmatter verbatim, followed by the page body reduced to plain markdown:

curl -s https://docs.allora.network/raw/get-started/quickstart-agents.md | head -9

---
title: Agent quickstart
description: An operating guide for AI coding agents — load the machine-readable docs, apply the guardrails, and submit and consume a live testnet inference without human input.
persona: AI coding agent
verified_against: allora-sdk-py (github.com/allora-network/allora-sdk-py) on allora-testnet-1 (emissions/v10); live api.allora.network v2 responses; allora-forge-builder-kit main (2026-07-22)
last_reviewed: 2026-07-30
---

# Agent quickstart

The frontmatter keys are the same five every page carries: title, description, persona, verified_against (what the content was checked against), and last_reviewed (YYYY-MM-DD).

Five things differ from the page's MDX source, all of them so that the file stands on its own:

• Code snippets are inlined. Many code blocks on the site pull their body from a runnable file in the repository, so the fence in the source is empty. In the raw markdown the snippet's actual contents are already there, exactly as the rendered page shows them.
• Links are absolute. Internal links become full https://docs.allora.network/... URLs, because a detached .md file has no page to resolve ./sibling against.
• Layout components are unwrapped. Callouts, tabs, and card grids become their text content, and a layout component that occupies a line of its own is dropped — it has nothing but its tag. One used mid-sentence becomes markdown of the same meaning: a component wrapping code becomes a backtick code span.
• Data components are rendered. The tables the site builds from the JSON manifests — the endpoint tables on Networks, the topic tables on Existing Allora Network Topics — are written out as markdown tables carrying the same values, read from the same manifests at generation time. A field a manifest omits is an em dash, exactly as on the page. Fetch /api/networks.json (opens in a new tab) or /api/topics.json (opens in a new tab) if you would rather have the JSON.
• Versions are resolved, never placeheld. Every current version in these docs comes from /api/versions.json, written in the source as a component or as a constant interpolated into a command. Both are replaced by the version string itself, read from that same file at generation time — so an install command in the raw markdown is copy-paste complete, and a version you read here is the version the page shows. Generation fails rather than publish an unresolved placeholder.

Headings, prose, tables, and code are otherwise the page's own text, in the page's own order. No component survives as a literal tag: a component the generator does not know how to reduce stops the build, so a page cannot ship here with a piece of itself missing.

JSON manifests

Three files under /api/ carry the facts that go stale on their own — chain state, endpoints, and versions — so you can read them instead of parsing prose.

/api/topics.json

Every topic currently active on each network. A nightly job queries each network's Cosmos LCD (REST) API, keeps only topics whose is_topic_active query returns true, and proposes the regenerated file for review. It is the same data the Existing Allora Network Topics page renders.

curl -s https://docs.allora.network/api/topics.json

{
  "generated_at": "2026-07-31T14:57:07Z",
  "source": "Cosmos LCD (REST) emissions API: next_topic_id, is_topic_active, topics",
  "networks": [
    {
      "network": "testnet",
      "chain_id": "allora-testnet-1",
      "emissions_api": "v10",
      "lcd": "https://allora-api.testnet.allora.network",
      "active_topic_count": 39
    }
  ],
  "topics": [
    {
      "network": "testnet",
      "chain_id": "allora-testnet-1",
      "id": 1,
      "metadata": "ETH 10min Prediction",
      "epoch_length": 120,
      "loss_method": "mse",
      "category": "price",
      "sandbox": false
    }
  ]
}

epoch_length is in blocks, category is price, log-return, or volatility, and sandbox marks the no-penalty onboarding topics. Topic IDs are per chain: the same prediction task has different IDs on testnet and mainnet.

The generated_at field says when the published copy was built — read it rather than assuming a cadence, and confirm a topic against the chain before building against it:

curl -s https://allora-api.testnet.allora.network/emissions/v10/is_topic_active/69

/api/networks.json

The network endpoints manifest, with one entry per network under networks (today testnet and mainnet). Each entry carries the chain ID, the deployed allora-chain release, the versioned emissions namespace to use in LCD and gRPC query paths, and the RPC, gRPC, LCD, explorer, and faucet URLs — faucet is omitted on networks that have none, so treat it as optional. It also carries sandbox_topic_ids, the topics on that network that need no whitelist and carry no penalty, which is the only place that list is declared: the topics job reads it from here to set the sandbox flag in /api/topics.json. The file documents its own fields in a field_notes object and records when it was last updated in updated. Networks is the prose reference, and its tables render from this same file.

curl -s https://docs.allora.network/api/networks.json

/api/versions.json

The current version of each Allora component the docs reference, so you can pin an install without scraping prose. Four version keys: chain_testnet and chain_mainnet, the allora-chain release each network is running — a deployment fact rather than something you install; allora_sdk, the Python SDK's release on PyPI; and builder_kit, the version of the Forge Builder Kit. The chain keys carry a leading v and the package versions do not, so add or strip it to match whatever you are pinning.

A fifth key, superseded, is not a version: it maps each of those four keys to the values it has already moved past, appended whenever the version is bumped. Read it if you need to tell "old release of ours" from "version of something else" — a build gate uses it to fail the docs when a superseded value is still written down as a current one. Its arrays are empty until the first bump.

curl -s https://docs.allora.network/api/versions.json

So a reader of this file should take the four top-level string values as the current versions, and superseded as history — not as a fifth component.

How these files stay current

llms.txt, llms-full.txt, and everything under /raw/ are generated from the page sources on every build of the site and committed to the docs repository (opens in a new tab); continuous integration fails a pull request whose generated files no longer match its pages. They therefore ship with the page edit that caused them, never behind it.

The manifests under /api/ are not tied to the page build. Each has a scheduled check behind it that opens a pull request when its upstream source moves, so a manifest is as current as the last proposal a human accepted — which is why topics.json publishes its own generated_at and networks.json its own updated.

How much of each file that automation covers differs, which matters if you are reasoning about staleness. topics.json is regenerated in full from each network's LCD. In networks.json, only abci_version — the build string the network reports over RPC — is written automatically; the endpoints, the emissions namespace, and deployed_version are maintained by hand. In versions.json, only versions actually published upstream are written automatically; chain_testnet and chain_mainnet record which release a network is running, which no release feed can tell you, so a human confirms and applies those. Read the freshness metadata a manifest carries rather than assuming a cadence, and for anything you are about to spend gas on, confirm it against the chain.

Related

• Agent quickstart — guardrails and a runnable end-to-end task for AI coding agents.
• Networks — chain IDs, RPC, LCD, and explorer endpoints in prose.
• Existing Allora Network Topics — the topic tables rendered from /api/topics.json.