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

# GetSales documentation

> A typed REST API and MCP server for the whole outbound stack: tables of people and companies, enrichment, data sources, multichannel workflows, the team inbox with its AI SDR, website signals, billing and webhooks.

GetSales runs outbound as one product. Playtables hold the people and companies with their enrichment columns and the data sources that fill them, Workflows run the LinkedIn and email steps, Unibox keeps every thread in one inbox next to the AI SDR that answers in it, Signals watches your website and your senders' profile views, and the integrations service connects all of it to your own APIs, CRMs and webhook receivers. Everything the app does is exposed twice from one schema: as typed REST endpoints, and as MCP tools an AI agent can call.

## The API surface

Five services, one contract style. Every endpoint authenticates the same way, returns the same response envelope, and fails with the same error taxonomy.

| Service | Base URL | What it covers |
| - | - | - |
| Playtables | `https://beta.getsales.io/playtables/v1` | Tables, views and columns, people and companies, pipeline stages, plays and notes, data sources and imports, the stoplist, the activity feed, the credit ledger, workflows with their records, tasks and sources |
| Unibox | `https://beta.getsales.io/unibox/v1` | Conversations, messages and the timeline, manual tasks, sender profiles with their LinkedIn account and mailboxes, the AI SDR agents with their scenarios, plans, runs, knowledge and memory |
| Signals | `https://beta.getsales.io/signals/v1` | Registered websites with key pages and tracked events, sessions and visitors, profile view sightings, the Signals page preferences |
| Integrations | `https://beta.getsales.io/integrations/v1` | Provider connections and the priced provider catalog, custom HTTP tools over your own APIs, the provider call log, webhook subscriptions and their delivery log |
| ID and Teams | `https://beta.getsales.io/id/v1` | The signed-in account, workspaces and members, sessions, API keys, OAuth clients and consents, billing, white label brands, notifications |

Paths in the reference are relative to these base URLs. `POST /api/playtables/search` means `POST https://beta.getsales.io/playtables/v1/api/playtables/search`. A bare `/api/...` path on the app host is not an API route: the prefix is part of the path.

## Start here

> [card] [Quickstart](https://docs.getsales.io/quickstart.md)
>
> Mint an API key and make your first call in a few minutes.

> [card] [Authentication](https://docs.getsales.io/authentication.md)
>
> API keys, OAuth access tokens, session JWTs and the Team-SID header.

> [card] [API reference](https://docs.getsales.io/api-reference/overview.md)
>
> Every endpoint of the five services, with an interactive playground.

> [card] [Receive webhooks](https://docs.getsales.io/guides/receive-webhooks.md)
>
> Subscribe an endpoint, verify signed deliveries, read the delivery log.

> [card] [MCP server](https://docs.getsales.io/mcp/overview.md)
>
> Give Claude, Cursor or ChatGPT the same tools over the Model Context Protocol.

> [card] [Changelog](https://docs.getsales.io/changelog.md)
>
> What shipped, in the order it shipped.

## How the contract behaves

* Every success body is an envelope: `success: true`, one typed `operation` shape (`search`, `get`, `create`, `update`, `delete`, `metrics`, `action`), and a `meta` block with a `trace_id` you can quote to support.
* Every failure is one `McpError` envelope with a code from a fixed 16-code taxonomy, so you map errors once and reuse the mapping everywhere. See [Envelopes and errors](https://docs.getsales.io/concepts/envelopes-and-errors.md).
* Lists page with `page_size` plus an opaque forward `cursor`, and filters are typed per field. See [Pagination and filtering](https://docs.getsales.io/concepts/pagination-and-filtering.md).
* Endpoints marked deprecated in the reference are `501` stubs: the request contract is final and validated, but the capability has not shipped yet. Build against them, do not ship against them. The reason is in each operation's description.

## Where the reference comes from

The reference is generated from the same registry that defines the MCP tools, one endpoint per tool. It is not written by hand, so what the playground shows is what the server actually validates.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.