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

# Overview

> Summation's public REST API for OpenAPI-described access to projects, catalog, queries, conversations, artifacts, files, connections, and workflows.

Everything the Summation app, the Addison plugins, the [MCP server](/integrations/mcp-server), and [sumcli](/api/cli) do runs on one public REST API:

```text theme={null}
https://api.summation.com
```

## The contract is the documentation

The live OpenAPI document is the source of truth for routes, schemas, parameters, and examples:

```text theme={null}
https://api.summation.com/openapi.json
```

Discover operations from the contract rather than hardcoding paths; the API evolves and `operationId`s, tags, and schemas are maintained there first.

The **Endpoints** section of this tab is generated directly from that document: every operation gets a page at `/api-reference/{area}/{operation}` with its parameters, request and response schemas, code samples, and a playground. Because the pages come from the contract, they stay in step with the API.

## Start here

<CardGroup cols={2}>
  <Card title="CLI" icon="terminal" href="/api/cli">
    `sumcli` covers this whole surface and handles token exchange for you. Start here unless you need raw HTTP.
  </Card>

  <Card title="Authentication" icon="key" href="/api/authentication">
    Get a bearer token: device login for people, M2M credentials for automation.
  </Card>

  <Card title="Conventions" icon="list-check" href="/api/conventions">
    Errors, streaming, pagination, and rate limits.
  </Card>

  <Card title="Resources" icon="book-open" href="/api/conversations">
    Per-area guidance: conversations, projects and files, reports, workflows, tables, connections.
  </Card>
</CardGroup>

## What's available

| Area                  | Typical operations                                                               |
| --------------------- | -------------------------------------------------------------------------------- |
| Projects              | list, create, manage catalog entries                                             |
| Catalog               | tables, views, schemas, sample data, lineage                                     |
| Query                 | bounded read-only SQL execution                                                  |
| Conversations         | chat with Addison (server-sent events)                                           |
| Reports               | generate (SSE), verify, export Markdown/PDF/DOCX                                 |
| Files                 | upload, download, import to tables                                               |
| Connections           | create, test, browse data sources                                                |
| Playbooks & workflows | recurring runs with email and Slack delivery                                     |
| Verification tests    | custom test definitions, scoped add/removal overlays, and effective-set previews |

The **Resources** in this tab cover each area's operations plus the semantics the contract can't express: which writes are full replaces, which calls send real email, and where the app and the API disagree on naming. Start there rather than with the raw endpoint list.

Not everything the product does has an API yet. [API coverage](/api/coverage) is the honest list of what's missing.

## Custom verification tests

Administrative clients can manage declarative custom tests, which extend [artifact verification](/features/artifacts/verification), through the stable public surface:

| Operation                                        | Purpose                                                                       |
| ------------------------------------------------ | ----------------------------------------------------------------------------- |
| `POST /v1/verification-tests`                    | Validate and create a `custom-test-bundle/v1` bundle                          |
| `GET /v1/verification-tests`                     | List definitions, optionally filtered by subject type                         |
| `POST /v1/verification-tests/attachments`        | Add a definition or create a removal overlay; removals require `confirm=true` |
| `GET /v1/verification-tests/attachments`         | List active raw attachments and their detachable ids                          |
| `DELETE /v1/verification-tests/attachments/{id}` | Soft-detach one attachment; requires `confirm=true`                           |
| `GET /v1/verification-tests/effective`           | Preview the inherited resolved test set and provenance                        |

Scopes are `tenant`, `project`, and `artifact`. Tenant scope derives the organization from the
authenticated principal and rejects `scope_id`; project and artifact require one. An `op=remove`
overlay suppresses a test ref from the resolved set and requires `confirm=true`. Detaching an
attachment removes the overlay row itself; these are intentionally different operations. Tenant-wide
writes are available only to organizations approved for verification-policy administration.

Use [`sumcli verification-tests`](/api/cli) for offline YAML/JSON validation and operator cross-org workflows;
the trusted target-org transport detail is not part of the public OpenAPI contract.

<Note>
  Building an agent rather than an app? The [MCP Server](/integrations/mcp-server) wraps this API in curated tools with the safety rails already in place: a deliberately narrower, non-destructive subset.
</Note>