> ## Documentation Index
> Fetch the complete documentation index at: https://docs.upsidemax.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# LLMs.txt for Upside

> Use Upside machine-readable Markdown documentation with coding assistants, custom agents, and retrieval pipelines.

Upside publishes machine-readable documentation files that coding assistants and custom agents can consume without parsing the rendered website. Use them to discover the API surface, retrieve implementation details, generate integration code, and ground agent responses in the current documentation.

<Note>
  The machine-readable files describe the API; they do not grant access or bypass signing. Read requests still use `POST /info`, while state-changing requests require a valid signed envelope sent to `POST /exchange`.
</Note>

## Available files

<CardGroup cols={2}>
  <Card title="llms.txt" icon="list" href="https://upside.mintlify.app/llms.txt">
    A compact index of documentation pages with titles, descriptions, and links. Start here when an agent needs to discover the right source before loading more context.
  </Card>

  <Card title="llms-full.txt" icon="file-lines" href="https://upside.mintlify.app/llms-full.txt">
    The full published documentation rendered as one Markdown document. Use it for broad code-generation tasks, offline indexing, or retrieval pipelines.
  </Card>
</CardGroup>

```text theme={"system"}
https://upside.mintlify.app/llms.txt
https://upside.mintlify.app/llms-full.txt
```

## Which file should you use?

| Task                                         | Recommended source               | Why                                                           |
| -------------------------------------------- | -------------------------------- | ------------------------------------------------------------- |
| Find the page for an endpoint or concept     | `llms.txt`                       | Fast, compact discovery with minimal context usage            |
| Answer a focused integration question        | `llms.txt`, then the linked page | Keeps the context narrow and easier to verify                 |
| Generate a client spanning several API areas | `llms-full.txt`                  | Provides read, write, signing, and WebSocket context together |
| Build a documentation search or RAG index    | `llms-full.txt`                  | One normalized Markdown corpus is easy to chunk and embed     |
| Keep a long-running agent context fresh      | `llms.txt` plus selected pages   | Avoids repeatedly loading the full corpus                     |

<Tip>
  Prefer a two-stage retrieval flow: use `llms.txt` to select the relevant pages, then load only those pages. Reserve `llms-full.txt` for tasks that genuinely require cross-document context.
</Tip>

## Recommended retrieval workflow

<Steps>
  <Step title="Fetch the index">
    Load `llms.txt` and identify the pages related to the user's task, such as authentication, order placement, account state, or WebSocket subscriptions.
  </Step>

  <Step title="Retrieve authoritative pages">
    Fetch the selected documentation pages and keep their URLs or paths alongside the extracted text so the agent can cite its source.
  </Step>

  <Step title="Generate a structured proposal">
    Ask the model for typed data or code rather than an unstructured instruction. For trading actions, require a JSON proposal that can be validated before signing.
  </Step>

  <Step title="Validate outside the model">
    Apply strict schemas, precision rules, risk limits, allowed-action lists, and nonce management in deterministic application code.
  </Step>

  <Step title="Refresh when the docs change">
    Re-fetch the index at application startup or on a controlled schedule, then update only the changed pages in your local cache or retrieval index.
  </Step>
</Steps>

## Use with coding assistants

### Claude Code or similar CLI agents

Fetch the full document when the task spans multiple sections:

```text theme={"system"}
/fetch https://upside.mintlify.app/llms-full.txt
```

For a focused task, fetch the index first and then the specific page it points to.

### Cursor, Windsurf, and IDE assistants

Add one of the URLs as a documentation source in the project's context settings. Use `llms.txt` for everyday lookup and `llms-full.txt` for repository-wide client generation or refactoring.

A useful project rule is:

```text theme={"system"}
Before implementing or changing Upside DEX integration code, consult the
machine-readable documentation. Do not infer request fields or response shapes
from naming alone. Link each non-obvious implementation choice to its source page.
```

### Custom agents

Fetch the index with `curl`:

```bash theme={"system"}
curl -fsSL https://upside.mintlify.app/llms.txt
```

Download the full corpus:

```bash theme={"system"}
curl -fsSL https://upside.mintlify.app/llms-full.txt \
  -o upside-llms-full.txt
```

A minimal Python loader:

```python theme={"system"}
from __future__ import annotations

import requests

DOCS_URL = "https://upside.mintlify.app/llms.txt"


def load_docs(url: str = DOCS_URL) -> str:
    response = requests.get(url, timeout=20)
    response.raise_for_status()
    return response.text


documentation_index = load_docs()
print(documentation_index[:500])
```

## Prompt recipes

### Endpoint discovery

```text theme={"system"}
Using the Upside documentation index, identify the smallest set of pages
needed to implement this task. Return the page URLs first, then summarize the
required endpoint, request fields, response fields, signing requirements, and
failure cases. Do not write code until the sources are identified.
```

### Code generation

```text theme={"system"}
Generate a production-oriented implementation from the cited Upside pages.
Use exact field names and preserve documented numeric types. Separate payload
construction, validation, signing, transport, and response reconciliation.
Never include a real private key or secret in examples.
```

### Payload review

```text theme={"system"}
Compare this proposed request against the Upside documentation. Report:
1. unknown or missing fields,
2. type or precision mismatches,
3. signature and nonce requirements,
4. unsafe assumptions,
5. the corrected payload.
Cite the documentation page supporting each correction.
```

## Building a retrieval index

When indexing `llms-full.txt` for retrieval-augmented generation:

* Split primarily at page titles and section headings rather than arbitrary character counts.
* Store each chunk with its page URL, heading path, and document version or fetch time.
* Keep code blocks with the paragraph that explains them.
* Give authentication, nonce, error handling, and action-specific pages higher retrieval priority for write operations.
* Return source links with every generated answer so developers can verify the recommendation.
* Treat retrieved documentation as context, not executable authority; validate all generated writes independently.

## High-value documentation paths

<CardGroup cols={2}>
  <Card title="Authentication" icon="signature" href="/guide/authentication">
    Canonical JSON, signed-message construction, keccak256, and ECDSA signature formatting.
  </Card>

  <Card title="Nonce" icon="clock" href="/guide/nonce">
    Uniqueness and replay-protection requirements for every signing address.
  </Card>

  <Card title="Read API" icon="download" href="/info/overview">
    Market, account, agent, and order queries through `POST /info`.
  </Card>

  <Card title="Write API" icon="upload" href="/exchange/overview">
    State-changing actions and the shared `POST /exchange` envelope.
  </Card>

  <Card title="WebSocket" icon="wave-pulse" href="/websocket/overview">
    Real-time market and private account streams for synchronized agent state.
  </Card>

  <Card title="Agent wallets" icon="key" href="/agents/api-wallets">
    Authorization, expiry, monitoring, rotation, and revocation for automated signers.
  </Card>
</CardGroup>

<Warning>
  Do not place private keys, seed phrases, signing-service credentials, or unrestricted production permissions in an LLM context. The model should produce an intent or unsigned payload; a separate trusted service should validate and sign it.
</Warning>
