Skip to main content
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 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 regardless of who’s calling it.

​
How this site is organized

Documentation

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.

APIs

The full technical reference: every endpoint’s parameters, request/response fields, and error cases.

MCP Server

Connect an agent (Claude Code, Claude Desktop, or your own) to AnyCRM via the Model Context Protocol.

​
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:

​
The core resources

Contacts

People — leads and customers. Move through the funnel target → lead → contact.

Deals

Sales opportunities on an account, tracked through a configurable pipeline of stages.

Accounts

Companies — the entity deals and contacts roll up to.

Activities

Calls, emails, meetings, and tasks logged against a deal, account, or contact.
Supporting resources — tags, files & folders, notifications, and 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, Outreach, AnyCard (plus AnyCard Events and Share Links), AI and Analytics Assistant, 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.
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.

​
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 for how to mint one and which scope each endpoint requires. The exceptions are the bootstrap and public-by-design routes: Exchange a token 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.

​
Conventions used in this reference

  • Auth on each endpoint names the scope(s) required — see 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 for the three conventions and how to page safely against each.