This page is a reference map, not an exhaustive generated API. The current repository exposes a website content system and a small development route. It does not expose a production protocol API, wallet API, node API, generated SDK, or RPC catalog. Future implementation work should add generated references from real source code and tests when those surfaces exist.

The main risk for an API page is false precision. A table of invented endpoints can look useful while creating concept drift. This reference therefore separates four layers: current website routes and content APIs, conceptual protocol API vocabulary, future generated implementation APIs, and external interface expectations.

API Layer Map

Use this map when reading any API claim. If the claim points to src/lib/content or a current route handler, it is website evidence. If it points to whitepaper vocabulary, it is conceptual protocol evidence. If it points to a future module that does not exist yet, it must be marked “not yet generated.”

Current Website Surfaces

The current local content surface includes:

• src/lib/content/docs.ts, which loads docs pages, frontmatter, domain metadata, navigation records, table of contents data, and rendered page content.
• src/lib/content/markdown.ts, which configures Markdown rendering features including diagrams, alerts, tabs, containers, footnotes, and task lists.
• src/lib/content/html.ts, which sanitizes and renders HTML documents with controlled script behavior.
• content/docs, which stores documentation pages and section indexes.
• config/content-pipeline.yaml, which controls pipeline features.

These modules are internal website APIs. They are stable enough for the docs site to use, but they are not public protocol interfaces. A Server Component can call local content functions directly. External users should not treat those functions as network APIs.

The current route surface in this scope includes src/app/api/dev/content-version/route.ts. It returns a JSON content version only in development and returns 404 outside development. That behavior is deliberately narrow. It should not be cited as network status, node health, wallet synchronization, or settlement maturity.

Conceptual Protocol Vocabulary

The Corpus Terminology Reference and Main Whitepaper provide the terms future APIs should preserve. Important names include AssetLeaf, RightLeaf, VoucherLeaf, SettlementLeaf, SettlementPath, Checkpoint, SettlementTheorem, ReceiverCard, PaymentRequest, TxPackage, ClaimTxPackage, CheckpointExecInput, CheckpointArtifact, and CheckpointLink.

These terms are conceptual unless backed by implementation code. They should guide naming and schema design, but they should not be documented as exported functions, endpoints, or classes until they exist. For example, a future generated API may expose submit_tx_package, but this repository should not list that as a runnable method unless source code and tests define it.

Vocabulary consistency still matters now. If docs pages use different names for the same object, builders will implement incompatible concepts later. This reference should therefore act as a map from current docs language to future implementation language.

Future Generated APIs

Future generated API references should come from real source artifacts. Good inputs include TypeScript types, OpenAPI specs, Rust docs, protobuf schemas, JSON schema files, route handlers, SDK source, or CLI definitions. Generated references should include request and response shapes, versioning, error classes, authentication requirements, privacy-sensitive fields, maturity labels, and examples that can be tested.

Until those artifacts exist, the correct status is “not yet generated.” A page can explain the intended layer and constraints, but it should not manufacture method signatures. When the implementation arrives, the generated reference should replace speculative tables rather than sit beside them as a parallel authority.

Not Yet Generated

The following reference surfaces are not generated by this repository today:

• Protocol RPC method catalog.
• Wallet SDK reference.
• Rollup node operator API.
• Settlement storage API.
• Useful-work evaluator API.
• Cross-chain locker or rights API.
• Public support or disclosure API.
• Browser WASM wallet API.
• Production network status API.

These surfaces may be valid future work. They are not live docs-repo APIs. Any tutorial that depends on them should say “target architecture” or “future implementation” and link to the whitepaper sections that justify the concept.

Transport Boundaries

Future external APIs will likely include JSON or JSON-RPC-style transport. The RPC page covers that boundary in detail. For this reference page, the rule is that transport shape is not settlement authority. A method that returns “accepted” must define accepted by whom: transport validator, publication service, node validation, data availability, checkpoint process, or final settlement. A method that returns a proof must identify proof type, root source, domain, and verification method.

External interfaces should also define privacy-sensitive fields. Wallet IDs, receiver material, proof hints, policy text, support evidence, timing data, recovery records, and telemetry should not appear in generic examples unless the privacy boundary is explained.

Evidence-Linked API Concepts

An API concept is ready for documentation when it has evidence. Evidence can be one of four types:

• Local source evidence: concrete files under src/, config/, scripts/, or content/.
• Whitepaper evidence: a named section in the corpus defining the concept.
• External standard evidence: an official spec such as JSON-RPC or RFC 8259.
• Test evidence: deterministic validation proving behavior.

If a claim has only whitepaper evidence, it should be conceptual. If it has source and test evidence, it can be implementation-facing. If it has neither, it should not be in the API reference.

Reference Table Rules

When generated references are added later, each table should identify the layer, maturity, source file, test evidence, and privacy class. A method table without those fields is likely to imply more authority than it has. For example, a publication method should distinguish transport receipt from data availability, checkpoint maturity, and settlement. A wallet method should identify whether it handles local payloads, network publication, recovery, or selective disclosure. A support method should identify the evidence package and redaction policy.

Reference examples should be executable only when the backing endpoint or function exists. Otherwise they should be pseudo-structures labeled as target schema sketches. This protects readers from copying commands that cannot run and protects implementers from treating docs fiction as an API contract.

Current Route Caveat

The development content-version route is intentionally narrow. It can help the local docs app know that content changed during development. It is not a health check for Z00Z network state, not a watcher status endpoint, not a protocol version endpoint, and not a public discovery mechanism. If future pages need network status, they should wait for a real status service or node API and cite that implementation.

The same caveat applies to content loader functions. They are reliable evidence for how docs are loaded, but they are not SDK APIs. Avoid naming them in public protocol tutorials unless the tutorial is explicitly about this website repo.

Naming Stability

API names should be stable because downstream builders copy them. When the corpus already defines a term, prefer that term over a friendlier synonym that changes meaning. For example, do not alternate between settlement path, storage path, proof path, and route path unless each term is intentionally different. Do not rename PaymentRequest to “payment link” in an API table if the protocol concept is a payment request with receiver material and policy context.

If a future implementation chooses a different exported name, the reference should explain the mapping instead of letting docs drift. One table can map canonical concept, exported type, route or method, source file, maturity, and test evidence. That kind of table is useful only after real source exists. Before that point, prose with explicit source links is safer than invented reference rows. Evidence should lead every exported name.

Read Next

• RPC for request, response, validation, and error boundaries.
• Examples And Tutorials for avoiding fake API examples.
• Verification And Tests for source-anchor and review checks.

Evidence and Further Reading

Use the source bullets below as an audit checklist, not decoration: when reusing this page, preserve the named section scope, the responsible actor, and the split between live repository evidence, target architecture, and open design work.

• src/lib/content/ for current internal content APIs.
• src/app/api/ and src/app/api/dev/content-version/route.ts for current website route evidence.
• Corpus Terminology And Abbreviations Reference section 3 for canonical protocol vocabulary.
• Main Whitepaper sections 3-4 for object and rollup boundary vocabulary.
• config/content-pipeline.yaml for current docs rendering configuration.