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

# Overview

> Authenticating and using the Slant public API

The Slant public API lets you read and manage CRM records (households, people, tasks, meetings, and more) from outside the app.

## Base URL

```
https://api.slant.app/v1
```

## Authentication

Every request must include an `Authorization` header using the `Bearer` scheme:

```
Authorization: Bearer slnt_pat_<token>
```

Tokens are issued from the [API connections settings page](/account-settings/api-tokens) on the **API** tab. Personal access tokens are **read-only by default**. To enable write access for a token, click **Enable write access** from the API token row and explain how you plan to use it. Write access is enabled immediately. Use `/v1/me` to check whether the current token can write.

## Quickstart

Verify your token with a request to `/v1/me`, which returns the currently authenticated user:

```bash theme={null}
curl https://api.slant.app/v1/me \
  -H "Authorization: Bearer slnt_pat_..."
```

```json theme={null}
{
  "id": "abc123xyz",
  "email": "you@example.com",
  "first_name": "Jane",
  "last_name": "Doe",
  "api_access": {
    "auth_type": "personal_access_token",
    "scope": "read_write",
    "can_write": true
  }
}
```

## Rate limits

Every request is checked against three buckets. The strictest bucket wins, and exceeded requests return `429 Too Many Requests`.

| Bucket                | Personal access token | OAuth app (default) |
| --------------------- | --------------------- | ------------------- |
| Per token / per user  | 1,000 req / hr        | 500 req / hr        |
| Per company / per app | 10,000 req / hr       | 1,000 req / hr      |
| Per IP                | 10,000 req / hr       | 10,000 req / hr     |

## Idempotency

Safely retry `POST` and `PATCH` requests by including an `Idempotency-Key` header with a unique value (a UUID works well):

```bash theme={null}
curl -X POST https://api.slant.app/v1/prospects \
  -H "Authorization: Bearer slnt_pat_..." \
  -H "Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000" \
  -H "Content-Type: application/json" \
  -d '{ "book_id": "...", "first_name": "Jane", "last_name": "Doe" }'
```

A repeated request with the same key and body returns the cached response instead of creating a duplicate. Keys live for **1 hour by default** and are scoped per endpoint — the same key on a different path creates a fresh record. `5xx` responses are never cached, so retries after a server error always re-execute.

## Request format

Requests with a body (`POST`, `PUT`, `PATCH`) must include `Content-Type: application/json`. Without it, the body is ignored and your fields come through empty. A malformed JSON body returns `400 invalid_json`.

## Conventions

* **Pagination** — list endpoints accept `page` (default 1) and `per_page` (default 25, max 100). Responses include `{ data: [...], pagination: { current_page, total_pages, total_count, per_page } }`.
* **IDs** — all IDs are opaque strings. Use them as-is.
* **Book scoping** — most endpoints accept an optional `book_id` query parameter. A "book" is an advisor's workspace. Use `GET /v1/books` to list the books your token can see.
* **Request bodies** — write endpoints use unwrapped JSON objects unless a specific endpoint says otherwise. Notes are a wrapped-body exception.
* **PATCH fields** — PATCH endpoints document their own request fields. Do not assume every POST field is accepted on PATCH.
* **Enum casing** — enum casing varies by endpoint. Use the exact case shown in each endpoint's request schema or example.
* **Timestamp filters** — filters such as `updated_since` use ISO 8601 timestamps, for example `2026-05-06T12:00:00Z`, not Unix seconds.
* **Filter matching** — email filters are exact matches after email normalization. Phone filters are exact E.164 matches. Name filters are prefix/full-text name matches, not arbitrary substring searches.
* **Assignment** — `assigned_to_id` should be a user ID from the relevant book's `GET /v1/books` `users[].id` list.
* **Deletes** — the v1 API does not expose DELETE for top-level CRM records. Use resource-specific lifecycle fields where available.
* **Errors** — `{ "error": "<code>", "detail": "<message>" }` with the appropriate HTTP status.