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

# Introduction

> What the AnyCRM API is, and how this documentation is organized

AnyCRM is a B2B sales CRM: **accounts** are companies, **deals** are sales opportunities on an account, and **contacts** are people. This site documents the REST API behind it, callable directly with an organization API key or personal access token, plus an [MCP server](/mcp/setup) for agent-based integrations.

There is no separate "public API" with a reduced surface — every endpoint documented here is a real production endpoint, gated by the same [scopes](/authentication#scopes) regardless of who's calling it.

## How this site is organized

<CardGroup cols={3}>
  <Card title="Documentation" icon="book-open" href="/concepts/contacts">
    Start here. Plain-language explanations of each entity and feature — what it is, how it fits together, and the business rules behind it. No endpoint tables.
  </Card>

  <Card title="APIs" icon="code" href="/api-reference/contacts/list-contacts">
    The full technical reference: every endpoint's parameters, request/response fields, and error cases.
  </Card>

  <Card title="MCP Server" icon="plug" href="/mcp/setup">
    Connect an agent (Claude Code, Claude Desktop, or your own) to AnyCRM via the Model Context Protocol.
  </Card>
</CardGroup>

## Base URL

The API is a single FastAPI service with no path prefix in front of resource routes — `GET /contacts`, `POST /deals`, etc. all hang directly off the origin:

```
https://crm-api.anyreach.ai
```

## The core resources

<CardGroup cols={2}>
  <Card title="Contacts" icon="user" href="/concepts/contacts">
    People — leads and customers. Move through the funnel `target` → `lead` → `contact`.
  </Card>

  <Card title="Deals" icon="handshake" href="/concepts/deals">
    Sales opportunities on an account, tracked through a configurable pipeline of stages.
  </Card>

  <Card title="Accounts" icon="building" href="/concepts/accounts">
    Companies — the entity deals and contacts roll up to.
  </Card>

  <Card title="Activities" icon="clock" href="/concepts/activities">
    Calls, emails, meetings, and tasks logged against a deal, account, or contact.
  </Card>
</CardGroup>

Supporting resources — [tags](/concepts/tags), [files & folders](/concepts/files-and-folders), [notifications](/concepts/notifications), and [reports](/concepts/reports) — round out the core surface and have their own guide pages, with full technical reference on the **APIs** tab.

Beyond the core CRM, each product area gets its own section on the **APIs** tab, most with a guide here too: [Customer Intelligence](/concepts/customer-intelligence), [Outreach](/concepts/outreach), [AnyCard](/concepts/anycard) (plus AnyCard Events and Share Links), [AI](/concepts/ai-features) and Analytics Assistant, [Account Readiness](/concepts/account-readiness), Integrations, Feedback, Public Media, and Service Health. Those reference pages are generated directly from the service's OpenAPI schema, so types, parameters and required/optional fields always match the running code — they just carry lighter narrative than the hand-written pages for the core resources, which add response-field and error tables the schema alone can't express.

<Note>Administrative endpoints — organization settings, membership, feature flags, provider health, and cross-organization outreach provisioning — are deliberately **not** documented here. They require admin or superadmin authority that an integration token doesn't carry, so they aren't part of the surface you build against.</Note>

## Authentication at a glance

Every endpoint documented on the **APIs** tab needs a bearer token: an **organization API key** (`ak_…`) or a **personal access token** (`pat_…`). See [Authentication](/authentication) for how to mint one and which scope each endpoint requires.

The exceptions are the bootstrap and public-by-design routes: [Exchange a token](/api-reference/pats/exchange) is unauthenticated because it's what mints a token in the first place, and the public AnyCard and media read endpoints are reachable by anyone with the link.

```bash theme={null}
curl https://crm-api.anyreach.ai/contacts \
  -H "Authorization: Bearer ak_xxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxx"
```

## Conventions used in this reference

* **Auth** on each endpoint names the scope(s) required — see [Scopes](/authentication#scopes).
* **Response** tables describe the JSON body of a `2xx` response. Most endpoints return the underlying database row(s) more or less as-is (this is a REST layer over Postgres via PostgREST, not a separately-versioned DTO layer), so response fields are documented against the actual table/view columns, not a hand-maintained schema that can drift.
* Every list endpoint returns a single page via `limit`/`offset`, but the **response envelope is not uniform** — some return a bare array with the total in an `X-Total-Count` header, some wrap the array in an object, and some return a bare array with no total at all. Each endpoint page states which shape it uses; see [Errors & Pagination](/errors-and-pagination#pagination) for the three conventions and how to page safely against each.