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

# Introduction

> The AutoSage API — architecture, conventions, and how to integrate.

The AutoSage API lets you provision tenants, ingest documents, build and run agents, and stream grounded conversations directly from your own application. If you are configuring AutoSage from the dashboard instead, see the [Product docs](/product/concepts).

## Base URL

All endpoints are served under a versioned prefix:

```
https://api.autosage.ai/api/v1
```

Authentication endpoints live under `/api/auth`, and invitation flows are served at the root. Each endpoint page notes its exact path.

## Conventions

<CardGroup cols={2}>
  <Card title="JSON everywhere" icon="brackets-curly">
    Requests and responses are JSON. Send `Content-Type: application/json` on requests with a body.
  </Card>

  <Card title="Bearer auth" icon="key">
    Authenticate with an API key: `Authorization: Bearer sk_...`. See [Authentication](/developers/authentication).
  </Card>

  <Card title="Schema-defined fields" icon="text">
    Field naming follows each endpoint schema and can mix styles. Use the endpoint reference or OpenAPI explorer for the exact request and response shape.
  </Card>

  <Card title="Predictable errors" icon="triangle-exclamation">
    Errors return the right HTTP status with a JSON message. `400` validation, `401/403` auth, `404` not found, `409` conflict.
  </Card>
</CardGroup>

## The resource hierarchy

The API mirrors the platform hierarchy. Almost every request resolves against it, and access is checked at each level:

```
Organization  →  Environment  →  Tenant  →  Knowledge base  →  Documents / Agents / Chats
```

An **API key is bound to a single environment** and carries the scopes and tenant/knowledge-base access it is allowed to use. Understanding this model is the key to designing a secure integration — start with [Tenancy](/developers/concepts/tenancy) and [Access & scopes](/developers/concepts/access-scopes).

## Two ways in

<CardGroup cols={2}>
  <Card title="Dashboard users" icon="user">
    People sign in with email/password or Google. Session-based auth powers the dashboard and admin operations like managing members and environments.
  </Card>

  <Card title="API keys" icon="robot">
    Your application authenticates with `sk_...` keys to provision resources and run chats — including on behalf of your own end users.
  </Card>
</CardGroup>

## Interactive reference

An OpenAPI-powered explorer is available at `/swagger` on the API host. These developer docs add the concepts, lifecycles, and guidance that the raw schema can't express.

## Essential guides

These guides begin with the product decision, then show the API implementation:

<CardGroup cols={2}>
  <Card title="KB prompts vs. agents" icon="scale-balanced" href="/guides/kb-prompts-vs-agents">
    Decide where shared behavior belongs and when you need a saved agent.
  </Card>

  <Card title="Chat vs. agent runs" icon="arrows-left-right" href="/guides/chat-vs-agent-runs">
    Understand chats, agents, runs, and the chat created for each run.
  </Card>

  <Card title="Share context between KBs" icon="share-nodes" href="/guides/share-context-between-kbs">
    Compose isolated knowledge bases through controlled delegation.
  </Card>

  <Card title="Agent in two minutes" icon="stopwatch" href="/guides/agent-in-two-minutes">
    Create version 1 and run it with the shortest valid API flow.
  </Card>
</CardGroup>

## Next steps

<Steps>
  <Step title="Get a key">
    Create an API key in the dashboard and learn how [authentication](/developers/authentication) works.
  </Step>

  <Step title="Make your first call">
    Follow the [quickstart](/developers/quickstart) to run a grounded chat end to end.
  </Step>

  <Step title="Go deeper">
    Read the [lifecycles](/developers/lifecycles/agent-lifecycle) to understand agents, chat, ingestion, and memory in detail.
  </Step>
</Steps>