# Documentation export

Import guides, API contracts and examples into your documentation, with stable identifiers and content hashes.

The [export manifest](/docs/export/manifest.json) lists the public guides, operation contracts and reusable examples from the same build as this site. It needs no API key. Fetch it from the environment you want to document:

```bash
curl --fail-with-body https://api.vultrinference.com/docs/export/manifest.json
```

## Read the manifest

`schema_version` is `1.0`. Resource URLs live under `/docs/export/v1/`; a breaking contract change uses a new versioned path. Resolve every root-relative URL against the origin from which you fetched the manifest. `canonical_url` is the human-readable source page on that origin; `api_url` is the public inference base URL.

The [JSON Schema](/docs/export/v1/schema.json) describes the manifest and each resource. The manifest carries its `schema_sha256`. Consumers should accept additive fields within version 1 and reject an unsupported major version.

| Field | Contains |
| --- | --- |
| `pages` | Descriptors with `id`, `url`, `sha256`, `title` and `kind` for every guide and operation page. |
| `operations` | Descriptors with operation ID, HTTP method, full API path and deprecation flag. |
| `examples` | Descriptors for the maintained examples used by guides and the generated operation samples. |
| `openapi` | The public bundled spec's URL and hash. |
| `live_sources` | Model data fetched separately: availability, parameters and prices can change without a docs build. |
| `revision` | A fingerprint of this static export. It does not change merely because time passed. |

Every descriptor's `sha256` is the SHA-256 of the exact response bytes, before JSON parsing and after HTTP content decoding. Keep the hash beside imported content; fetch a resource again only when its descriptor changes. The schema and OpenAPI document use the same hash convention. `revision` hashes the manifest serialized as indented JSON with a final newline, before adding the `revision` member; use it as an opaque fingerprint rather than reserializing it yourself.

All export resources support `GET`, `HEAD`, and `If-None-Match`. Save the returned `ETag` and send it on the next request; `304` means the response has not changed. Responses are cacheable for five minutes. A missing resource is a non-cacheable `404` JSON response.

## Import a page

For example, [the async jobs page export](/docs/export/v1/pages/concepts/async-jobs.json) has the stable ID `page:concepts/async-jobs`. The overview is `page:overview`; operation pages use `page:reference/<operationId>`.

`markdown` contains the complete published Markdown, with our directives expanded. `markdown_sha256` matches its UTF-8 bytes and the existing `markdown_url` response. `content_format` is `gfm+html`: tables, fenced code, callouts, and some HTML diagrams. Convert the elements your publishing system supports and report unsupported elements for review. Relative links and image sources must be resolved against `canonical_url` before importing; map links to your own imported pages where appropriate.

`headings` lists guide section IDs, levels and labels. Operation pages currently have no exported heading inventory. `dependencies` records explicit relationships declared in the guide's front matter and directives:

- `operations`: operation IDs, such as `create-video`.
- `schemas`: component schema names in the linked OpenAPI document.
- `examples`: example IDs, such as `example:guide/video-create-and-poll`.
- `model_types`: output types whose live model lists the guide uses, such as `video`.

These are declared dependencies, not an analysis of every claim or link in prose. Watch the linked operation/spec hashes as well as the page hash. A model list in expanded Markdown is a link to the live catalog, not a static list of models.

## Import contracts and examples

[An operation export](/docs/export/v1/operations/create-video.json) has ID `operation:create-video`, its public `contract`, and `example_id`. The contract is the bundled OpenAPI operation, including inherited path parameters and security. Local `$ref` values resolve against the full document at `openapi_url`, not against the export JSON. Verify that document against `openapi_sha256` before resolving its references.

[A maintained example](/docs/export/v1/examples/guide/video-create-and-poll.json) has ID `example:guide/video-create-and-poll`; [generated operation samples](/docs/export/v1/examples/operation/create-video.json) have ID `example:operation/create-video`. Each `variants` entry contains a language, display label, exact code and its own SHA-256 hash. Use these to render code tabs without copying snippets by hand.

`origin` is `maintained` for files included by a guide, or `generated` for samples made from the OpenAPI contract. Both say `verification: not_reported`: the export does not publish live-check results and does not assert that an example was executed. Use your own validation before publishing changes.

## Keep models and prices current

Fetch `live_sources.models.url` with ordinary HTTP and no `Anthropic-Version`, `X-TypeSafe-SDK` or OpenRouter SDK User-Agent; those select a different catalog shape. The default provider documents contain every output modality, parameter range and structured price, including conditional pricing overrides. Keep decimal prices as decimal strings. Do not reduce a multi-output model to its first output.

`live_sources.model_cards` is a small display feed; its short price label cannot replace the detailed pricing data. `live_sources.model_pages` is the current model index as Markdown. See [the catalog libraries](/docs/integrations/model-catalog) for reading the full catalog.

A catalog failure must not replace the last successful publication with an empty list. Treat absence from the live catalog as availability information, not a retirement notice. Limits and retention rules that exist only in guide prose are not a structured facts feed in version 1.

## Publish a consistent update

1. Fetch the manifest and validate its supported version and schema.
2. Fetch changed resources, then verify every advertised hash. Fetch and verify the linked OpenAPI document for contract references.
3. If a resource is missing or a hash disagrees, discard that candidate update and retry from a fresh manifest. A deploy may have occurred between requests.
4. Convert the supported content and produce a reviewable diff, preserving editorial sections outside generated content.
5. Publish only the complete validated update, then save its manifest and hashes.

The export contains public documentation only. Private platform routes, internal repository notes, credentials, and live verification reports are not included. Renaming a page changes its ID; an absent resource alone is not permission to delete downstream editorial content.